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
This CL sets the stage for retracting the SkPicture::kOptimizeForClippedPlayback_RecordingFlag flag
from the public API (more work needs to be done in Blink & Chrome). In the new world the only way
to set this flag (and thus instantiate an SkPicture-derived
class) is by passing a factory to the SkPictureRecorder class. This is to get all clients always using
factories so that we can then change the factory call used (i.e., so the factory just creates a BBH) and
do away with the SkPicture-derived classes.
BUG=skia:2315
R=reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/239703006
git-svn-id: http://skia.googlecode.com/svn/trunk@14221 2bbb7eff-a529-9590-31e7-b0007b416f81
Mike K: please sanity check Test.cpp and skia_test.cpp
Feel free to look at the rest, but I don't expect any in depth review of path ops innards.
Path Ops first iteration used QuickSort to order segments radiating from an intersection to compute the winding rule.
This revision uses a circular sort instead. Breaking out the circular sort into its own long-lived structure (SkOpAngle) allows doing less work and provides a home for caching additional sorting data.
The circle sort is more stable than the former sort, has a robust ordering and fewer exceptions. It finds unsortable ordering less often. It is less reliant on the initial curve tangent, using convex hulls instead whenever it can.
Additional debug validation makes sure that the computed structures are self-consistent. A new visualization tool helps verify that the angle ordering is correct.
The 70+M tests pass with this change on Windows, Mac, Linux 32 and Linux 64 in debug and release.
R=mtklein@google.com, reed@google.com
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/131103009
git-svn-id: http://skia.googlecode.com/svn/trunk@14183 2bbb7eff-a529-9590-31e7-b0007b416f81
When image filters are processed within Skia, they simply do
a blind recursion. This has the side-effect of turning the
DAG into a tree. I.e., nodes visited more than once during
the traversal will be processed more than once.
This change implements a very simple cacheing scheme: a
cache is created before traversing the DAG, and handed
into the processing traversal. Before recursing into a child
in SkImageFilter::filterImage(), the cache is checked for a
hit, and early-out is performed. Otherwise, the node is
processed, and its result bitmap and location (offset) are
cached, but only if it contains two or more children and
thus will be visited again during the traversal.
Currently, the child count is approximated with the
refcount. This is good enough in most cases (and exactly
correct for the Chrome use case). We could add an exact
child count to the image filter, but this will require
violating the immutability of image filters slightly in
order to bump the child count as nodes are connected. I
leave it up to the reviewer to decide which is better.
R=reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/230653005
git-svn-id: http://skia.googlecode.com/svn/trunk@14160 2bbb7eff-a529-9590-31e7-b0007b416f81
