On android trybots, the files in a subdirectory weren't being
loaded onto the device. Consequently, the ImageDecoderOptions
test was not testing anything. I had to relax that unit test
to reflect the existing behavior of our libjpeg decoder on
Android.
R=djsollen@google.com
Review URL: https://codereview.chromium.org/264583007
git-svn-id: http://skia.googlecode.com/svn/trunk@14682 2bbb7eff-a529-9590-31e7-b0007b416f81
The order of arguments in these structs is arbitrary, so we might as well arrange them to optimize something. Putting the paints at the front means the logic to find the paint is a lot more concise: it's usually just ptr+0, or *(ptr+0) when the SkPaint is optional.
This considerably reduces the size of the jump table in IsDraw::operator().
BUG=skia:2378
R=fmalita@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/272673002
git-svn-id: http://skia.googlecode.com/svn/trunk@14634 2bbb7eff-a529-9590-31e7-b0007b416f81
The cubic line intersection math empirically works 99.99% of the time (fails 3100 out of 1B random tests) but when it fails, an intersection may be missed altogether.
The binary search is may not find a solution if the cubic line failed to find any solutions at all, but so far that case hasn't arisen.
BUG=skia:2504
TBR=reed@google.com
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/266063003
git-svn-id: http://skia.googlecode.com/svn/trunk@14614 2bbb7eff-a529-9590-31e7-b0007b416f81
When verylargebitmap GM runs in cross-process pipe mode, we're
requestBlock()ing ~200M to carry the bitmaps. The current
implementation ends up allocating ~800M, which is a bit wasteful.
SkGPipeWrite already rounds up to 16K, so just rely on that.
This change exposed several bugs in pipe:
- we don't reserve enough space in drawVertices
- we don't reserve enough space for factory names in cross-process mode
- we don't quite have the right check in needOpBytes to see if we needed to send off the current block and allocate a new one
SETUP_NOTIFY and generally calling doNotify() more often than necessary made things hard to debug and understand. Now the pipe always waits to send off its current block until it needs more space than that block can provide, or it's the final block. We can put these back if we need the proactive flushing, but it seems not necessary?
Removed an assert in DeferredCanvasTest, which is somtimes 2 (Debug), sometimes 3 (Release). It seemed like the other asserts were more essential, and this one was more of a white-box assertion. Still sound if we remove it?
BUG=skia:2478
R=scroggo@google.com, mtklein@google.com, reed@google.com, junov@chromium.org
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/267863002
git-svn-id: http://skia.googlecode.com/svn/trunk@14613 2bbb7eff-a529-9590-31e7-b0007b416f81
If an saveLayer()/restore() is recorded, tilegrid/rtree will cull them
out and not draw anything. This is correct for most cases, but if the
paint in the saveLayer() is one that affects transparent black (e.g.,
it contains a color filter or image filter which affects transparent
black), this is incorrect: the filter should be applied.
Fixed by adding a no-op between the saveLayer() and restore(), and
adding a bbox node pointing at that node with the saveLayer()'s bounds.
This exposed a bug in SkPictureRecord.cpp's match(), where it would
assert if the NOOP was the last op seen. Fixed with an early-out before
calling peek_op_and_size().
BUG=skia:2254
Review URL: https://codereview.chromium.org/262363007
git-svn-id: http://skia.googlecode.com/svn/trunk@14604 2bbb7eff-a529-9590-31e7-b0007b416f81
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
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
