| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should be a drop-in replacement for most for-loops to make them run in parallel:
for (int i = 0; i < N; i++) { code... }
~~~>
sk_parallel_for(N, [&](int i) { code... });
This is just syntax sugar over SkTaskGroup to make this use case really easy to write.
There's no more overhead that we weren't already forced to add using an interface like batch(),
and no extra heap allocations.
I've replaced 3 uses of SkTaskGroup with sk_parallel_for:
1) My unit tests for SkOnce.
2) Cary's path fuzzer.
3) SkMultiPictureDraw.
Performance should be the same. Please compare left and right for readability. :)
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1184373003
|
| |
|
|
|
|
|
|
|
|
| |
This is necessary for multisampling, so that each multisampled render
target resolves before Chrome's compositor attempts to draw the
texture.
BUG=skia:
Review URL: https://codereview.chromium.org/878653004
|
| |
|
|
|
|
|
|
| |
Porting QuiltTask isn't important in itself; this is mostly an API feeler.
BUG=skia:
Review URL: https://codereview.chromium.org/689673003
|
| |
|
|
|
|
|
|
| |
SampleApp is multipicturedraw aware.
BUG=skia:
Review URL: https://codereview.chromium.org/684923002
|
|
|
This CL adds a new API to optimize across multiple SkPicture draw calls.
Note that multiple pictures rendered at once (i.e., picture piles) should be flattened into a single new picture that includes the required clipping on the different layers.
R=bsalomon@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/491313003
|
mtklein
senorblanco
reed
robertphillips