This is a mid-level library for finding patterns of commands in an SkRecord. At the API level, it's a bit regex inspired. Some examples:
- Pattern1<Is<DrawRect>> matches a single DrawRect
- Pattern1<Star<Is<DrawRect>>> matches 0 or more DrawRects
- Pattern2<Is<ClipRect>, Is<DrawRect>> matches a single clip rect followed by a single draw rect
- Pattern3<Is<Save>, Star<IsDraw>, Is<Restore>> matches a single Save, followed by any number of Draws, followed by Restore
- Pattern1<Or<Is<DrawRect>, Is<ClipRect>>> matches a DrawRect or a ClipRect
- Pattern1<Not<Is<ClipRect>>> matches a command that's notClipRect.
Once you have a pattern, you can call .search() on it to step through ranges of matching commands. This means patterns can replace most of the custom iteration logic for optimization passes: the generic pattern searching steps through all the optimization candidates, which optimization-specific code further inspects and mutates.
SkRecordTraits is now unused. Bye bye!
Generated code and performance of SkRecordOpts is very similar to what it was before. (I had to use SK_ALWAYS_INLINE in a few places to make this so.)
BUG=skia:2378
R=fmalita@chromium.org, bungeman@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/263063002
git-svn-id: http://skia.googlecode.com/svn/trunk@14582 2bbb7eff-a529-9590-31e7-b0007b416f81
Before this change, an object needed to inherit from GrResource (and
thus be a GPU object) in order to live in the GrResourceCache. That
was a problem for caching items that weren't GPU objects themselves,
but owned GPU objects.
This change splits GrResource into two classes:
1. GrCacheable: The base class for objects that can live in the
GrResourceCache.
2. GrGpuObject, which inherits from GrCacheable: The base class for
objects that get tracked by GrGpu.
This change is purely a refactor; there is no change in functionality.
Change-Id: I3e8daeb1f123041f414aa306c1366e959ae9e39e
BUG=skia:
R=bsalomon@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/251013002
git-svn-id: http://skia.googlecode.com/svn/trunk@14553 2bbb7eff-a529-9590-31e7-b0007b416f81
When matrix convolution processes border pixels with zero width, it
asserts in getAddr32() with an invalid x coordinate. The assert is
harmless, since the returned pointer is never accessed (the next line
is a loop from left to right, which does nothing, since left == right).
However, the fix is simple: early out on an empty rect before entering
the outer loop.
R=sugoi@chromium.org
Review URL: https://codereview.chromium.org/265693005
git-svn-id: http://skia.googlecode.com/svn/trunk@14497 2bbb7eff-a529-9590-31e7-b0007b416f81
The old code here wasn't being careful to avoid int32_t overflow in slow_check. Fix that.
R_ASSERT hasn't been doing anything for a while. As a result, there are a couple bugs in SkClampRange, marked as such and commented out. The asserts also weren't quite passing, so I fixed them up (allowing 0xFFFF to be considered either as part of the ramp or part of V1.)
BUG=skia:2481
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/260523004
git-svn-id: http://skia.googlecode.com/svn/trunk@14479 2bbb7eff-a529-9590-31e7-b0007b416f81
On Mike's suggestion, I tested out not doing any empty-clip check at all in
SkRecordDraw, given that mostly we'll do that again anyway inside SkCanvas.
Most SKPs are identical to the status quo, whether bot or silk, played back in tiles
or full. Average playback performance, both arithmetic and geometric mean, is also
unchanged.
A handful of SKPs do draw faster or slower reliably, particularly when tiled. E.g. a
cnn tile draws about 40% faster, a cuteoverload tile about 20% slower. Their profiles
look pretty much the same before and after, so I can't really explain the changes.
I'd say, given that performance is mostly identical and very identical in bulk,
we might as well remove this code. It's nice to keep SkRecordDraw as dumb as possible.
BUG=skia:2378
R=reed@google.com, fmalita@chromium.org, mtklein@google.com, borenet@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/258183002
git-svn-id: http://skia.googlecode.com/svn/trunk@14433 2bbb7eff-a529-9590-31e7-b0007b416f81
Add a new GM that exercises tiled drawing all pixel-moving filters
(and some non-pixel-moving ones) and compares it against non-tiled
drawing of the same filters. Fixing this test revealed that tile and
matrix convolution filters had no onFilterBounds() traversals
(test-driven development FTW). Tile requires (conservatively) the
bounds to include the whole source rect, since it may end up in the
result. Matrix convolution requires the bounds to be offset by the
kernel size and target.
R=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/258243005
git-svn-id: http://skia.googlecode.com/svn/trunk@14432 2bbb7eff-a529-9590-31e7-b0007b416f81
This CL begins the process of making SkPicturePlayback & SkPictureRecord independent of SkPicture. It just moves the PathHeap into SkPicture to get a feel for where all this is going to lead.
Some items of note:
SkTimedPicture (debugger/QT) should wind up being just an SkPicturePlayback-derived object.
All the flattening & unflattening should migrate out of SkPicturePlayback and into SkPicture.
SkPicture::initForPlayback should eventually become something just SkPictureRecorder::endRecording calls.
SkPicture is passed into SkPicturePlayback's & SkPictureRecord's constructors. SkPicturePlayback only
holds onto a "const SkPicture*". The SkPicturePlayback:: CreateFromStream & CreateFromBuffer methods pass a non-const
SkPicture* down the call stack.
BUG=skia:2315
R=reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/249453002
git-svn-id: http://skia.googlecode.com/svn/trunk@14341 2bbb7eff-a529-9590-31e7-b0007b416f81
This adds back two optimizations from SkPicture: drawPosText strength reduction to drawPosTextH, and pointless save-foo-restore blocks are noop'd away.
The small-T optimization in SkRecord gets in the way of implementing replace(), so I removed it.
Just to keep the API focused, I removed the methods on SkRecord that iterate over i for you; it's just as efficient to do it yourself, and all of the interesting code does its own custom iteration.
BUG=skia:2378
R=fmalita@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/245853002
git-svn-id: http://skia.googlecode.com/svn/trunk@14300 2bbb7eff-a529-9590-31e7-b0007b416f81
