| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fold alpha to the inner savelayer in savelayer-savelayer-restore
patterns such as this:
SaveLayer (non-opaque)
Save
ClipRect
SaveLayer
Restore
Restore
Restore
Current blink generates these for example for SVG content such as this:
<path style="opacity:0.5 filter:url(#blur_filter)"/>
The outer save layer is due to the opacity and the inner one is due to
blur filter being implemented with picture image filter.
Reduces layers in desk_carsvg.skp testcase from 115 to 78.
BUG=skia:3119
Review URL: https://codereview.chromium.org/835973005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fold alpha of a save layer call to the subsequent draw call paint, even when
the draw call paint color is already non-opaque.
Comparing the difference of the unoptimized and the optimized call pattern
with all (layer alpha, draw alpha) combinations, this produces
off-by-one pixels ~50% of the time.
Reduces layers of current desk_carsvg.skp (recorded with cross-process
picture image filters allowed) from 122 to 115.
BUG=skia:3119
Review URL: https://codereview.chromium.org/840483005
|
|
|
|
|
|
|
|
|
| |
They're only hints. We can ignore them in this optimization.
My only hesitation is that this pattern doesn't seem to happen in our .skps.
BUG=skia:
Review URL: https://codereview.chromium.org/849243002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/819123003
|
|
|
|
|
|
|
|
| |
patch from issue 759443006 at patchset 40001 (http://crrev.com/759443006#ps40001)
BUG=skia:
Review URL: https://codereview.chromium.org/767333002
|
|
|
|
|
|
|
|
|
|
|
| |
Recording gets a ~5% speedup.
BUG=skia:
R=robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/577673003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We optimize
Save
SaveLayer
Restore
Restore
into
NoOp
NoOp
NoOp
Restore
I'm considering skipping the call to SkRecordOptimize again just to eliminate
this extra variable from landing SkRecord. Thoughts?
BUG=skia:
R=robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/560163002
|
|
|
|
|
|
|
|
|
|
|
|
| |
These optimizations are outclassed by a general bounding-box hierarchy,
and are just going to make plugging that into SkRecordDraw more complicated.
BUG=skia:
R=robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/452983002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm soon going to have SkRecorder start calling getTotalMatrix(), which
would be broken in write-only mode. That change is big and nebulous,
but it's clear kWriteOnly needs to go, so we might as well kill it now.
My notes in bench_playback about kWriteOnly mode being important were
probably overly cautious. I now think this is a fair enough comparison
even re-recording into a read-write canvas.
BUG=skia:2378
R=fmalita@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/290653004
git-svn-id: http://skia.googlecode.com/svn/trunk@14963 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2378
R=reed@google.com, mtklein@google.com, robertphillips@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/290883004
git-svn-id: http://skia.googlecode.com/svn/trunk@14778 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2378
R=fmalita@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/277613002
git-svn-id: http://skia.googlecode.com/svn/trunk@14653 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Allow any return type from SkRecord mutators and visitors;
- update existing calls to mutate and visit;
- convert match to operator() in SkRecordPattern;
- tidy up a few inelegant bits of old code in tests.
The net result is that the generated code is much clearer. All the mutate() calls
inline as you'd hope, and you can now actually follow along with the disassembly.
BUG=skia:2378
R=fmalita@chromium.org, bungeman@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/273643007
git-svn-id: http://skia.googlecode.com/svn/trunk@14631 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
save-drawA-drawB-drawC-restore always means drawA-drawB-drawC,
no matter what flags we use for save().
This one triggers all over the silk SKPs and in several of the bot SKPs, typically as save-drawBitmap-restore.
BUG=skia:2378
R=robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/267793006
git-svn-id: http://skia.googlecode.com/svn/trunk@14618 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is like SkPictureRecord's remove_save_layer1 but works with all draw calls.
Interesting patterns removed:
SaveLayer-DrawRect-Restore: Silk SKPs, desk_weather
SaveLayer-DrawPath-Restore: desk_carsvg, desk_wowwiki, tabl_androidpolice
SaveLayer-DrawPosTextH-Restore: tabl_android_police
There may be others, but I stopped looking.
BUG=skia:2378
R=robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/269813010
git-svn-id: http://skia.googlecode.com/svn/trunk@14610 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- use REPORTER_ASSERT;
- assert the type first, then the pointer != NULL. This helps explain why ptr == NULL;
- add a simpler NoopSaveRestore test case, which can help debugging failures of the larger test case.
BUG=skia:2378
R=fmalita@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/264043012
git-svn-id: http://skia.googlecode.com/svn/trunk@14570 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
BUG=skia:2378
R=fmalita@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/251133008
git-svn-id: http://skia.googlecode.com/svn/trunk@14455 2bbb7eff-a529-9590-31e7-b0007b416f81
|