Reason for revert:
Breaks Ubuntu and Mac CMAKE
Original issue's description:
> Make SkPicture/SkImageGenerator default to SkCodec
>
> Remove reference to SkImageDecoder from SkPicture. Make the default
> InstallPixelRefProc passed to CreateFromStream use
> SkImageGenerator::NewFromEncoded instead.
>
> Make SkImageGenerator::NewFromEncoded create an SkCodecImageGenerator.
> Remove the old version that used SkImageDecoder.
>
> Remove all versions of lazy_decode_bitmap/LazyDecodeBitmap. The default
> now behaves lazily.
>
> Update all clients to use the default.
>
> Move SkImageDecoderGenerator into KtxTest.cpp, and use it directly.
>
> BUG=skia:4691
> BUG=skia:4290
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1671193002
>
> Committed: https://skia.googlesource.com/skia/+/026388a01864c74208ad57d1ba4f711602d101c6TBR=msarett@google.com,reed@google.com,scroggo@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4691
Review URL: https://codereview.chromium.org/1685963004
Remove reference to SkImageDecoder from SkPicture. Make the default
InstallPixelRefProc passed to CreateFromStream use
SkImageGenerator::NewFromEncoded instead.
Make SkImageGenerator::NewFromEncoded create an SkCodecImageGenerator.
Remove the old version that used SkImageDecoder.
Remove all versions of lazy_decode_bitmap/LazyDecodeBitmap. The default
now behaves lazily.
Update all clients to use the default.
Move SkImageDecoderGenerator into KtxTest.cpp, and use it directly.
BUG=skia:4691
BUG=skia:4290
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1671193002
Review URL: https://codereview.chromium.org/1671193002
To avoid breaking existing SKPs, add a deserialization stub which
unflattens SkBitmapSource records to SkImageSources.
R=reed@google.com,mtklein@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1363913002
Image encoding may fail during serialization, resulting in zero-length
encoded data in the SKP.
Instead of invalidating the stream (and preventing deserialization of
the whole picture) we can instantiate placeholder images.
BUG=skia:4285
R=reed@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1308273011
Old flow to serialize a picture:
1) serialize picture ops
2) serialize all sub pictures recursively
3) flatten the rest of this picture into a buffer, deduping flattenable factories and typefaces as we go
4) serialize the factories and typefaces
5) serialize the bytes from 3)
This allows the data in step 5) to refer to the deduplicated factories and typefaces from step 4). But, each sub picture in step 2) is completely siloed, so they can't dedup with the parent picture or each other.
New flow:
1) serialize picture ops
2) flatten the rest of this picture into a buffer, deduping flattenable factories and typefaces as we go
3) dummy-serialize sub pictures into /dev/null, with the effect of adding any new typefaces to our dedup set
4) serialize the factories and typefaces
5) serialize the bytes from 2)
6) serialize all sub pictures recursively, with perfect deduplication because of step 3).
Now all typefaces in the top-level picture and all sub pictures recursively should end up deduplicated in the top-level typeface set.
Decoding changes are similar: we just thread through the top-level typefaces to the sub pictures. What's convenient / surprising is that this new code correctly reads old pictures if we just have each picture prefer its local typeface set over the top-level one: old pictures always just use their own typefaces, and new pictures always use the top-level ones.
BUG=skia:4092
Review URL: https://codereview.chromium.org/1233953004
This requires we "first" add a has-picture bool to SkPictureShader serialized format.
BUG=chromium:486947, billions and billions of others.
Review URL: https://codereview.chromium.org/1151663002
This re-enables adoption tracking for SkPictures in Blink,
which should be green now that crrev.com/1136123011 has landed.
BUG=skia:3847
Review URL: https://codereview.chromium.org/1145153002
Reason for revert:
win_chromium_compile_dbg_ng
FAILED: ninja -t msvc -e environment.x86 -- E:\b\build\goma/gomacc "E:\b\depot_tools\win_toolchain\vs2013_files\VC\bin\amd64_x86\cl.exe" /nologo /showIncludes /FC @obj\third_party\skia\src\core\skia.SkBitmapHeap.obj.rsp /c ..\..\third_party\skia\src\core\SkBitmapHeap.cpp /Foobj\third_party\skia\src\core\skia.SkBitmapHeap.obj /Fdobj\skia\skia.cc.pdb
e:\b\build\slave\win\build\src\third_party\skia\include\core\skpicture.h(176) : error C2487: 'CURRENT_PICTURE_VERSION' : member of dll interface class may not be declared with dll interface
Original issue's description:
> Sketch splitting SkPicture into an interface and SkBigPicture.
>
> Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
> These cover about 89% of draw calls from Blink SKPs,
> and about 25% of draw calls from our GMs.
>
> SkPicture handles:
> - serialization and deserialization
> - unique IDs
>
> Everything else is left to the subclasses:
> - playback(), cullRect()
> - hasBitmap(), hasText(), suitableForGPU(), etc.
> - LayerInfo / AccelData if applicable.
>
> The time to record a 1-op picture improves a good chunk
> (2 mallocs to 1), and the time to record a 0-op picture
> greatly improves (2 mallocs to none):
>
> picture_overhead_draw: 450ns -> 350ns
> picture_overhead_nodraw: 300ns -> 90ns
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/c92c129ff85b05a714bd1bf921c02d5e14651f8b
>
> Latest blink_linux_rel:
>
> http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/61248
>
> Committed: https://skia.googlesource.com/skia/+/15877b6eae33a9282458bdb904a6d00440eca0ecTBR=reed@google.com,robertphillips@google.com,fmalita@chromium.org,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1130283004
Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
These cover about 89% of draw calls from Blink SKPs,
and about 25% of draw calls from our GMs.
SkPicture handles:
- serialization and deserialization
- unique IDs
Everything else is left to the subclasses:
- playback(), cullRect()
- hasBitmap(), hasText(), suitableForGPU(), etc.
- LayerInfo / AccelData if applicable.
The time to record a 1-op picture improves a good chunk
(2 mallocs to 1), and the time to record a 0-op picture
greatly improves (2 mallocs to none):
picture_overhead_draw: 450ns -> 350ns
picture_overhead_nodraw: 300ns -> 90ns
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/c92c129ff85b05a714bd1bf921c02d5e14651f8b
Latest blink_linux_rel:
http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/61248
Review URL: https://codereview.chromium.org/1112523006
I realized when writing the comment on https://crrev.com/1135363002/
that I'd really just sketched out the entire thing, so I couldn't help
but actually write up a working CL. How does this do for your benchmark?
BUG=chromium:487075
Review URL: https://codereview.chromium.org/1130123006
Reason for revert:
speculative revert to fix failures in DEPS roll
Original issue's description:
> Sketch splitting SkPicture into an interface and SkBigPicture.
>
> Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
> These cover about 89% of draw calls from Blink SKPs,
> and about 25% of draw calls from our GMs.
>
> SkPicture handles:
> - serialization and deserialization
> - unique IDs
>
> Everything else is left to the subclasses:
> - playback(), cullRect()
> - hasBitmap(), hasText(), suitableForGPU(), etc.
> - LayerInfo / AccelData if applicable.
>
> The time to record a 1-op picture improves a good chunk
> (2 mallocs to 1), and the time to record a 0-op picture
> greatly improves (2 mallocs to none):
>
> picture_overhead_draw: 450ns -> 350ns
> picture_overhead_nodraw: 300ns -> 90ns
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/c92c129ff85b05a714bd1bf921c02d5e14651f8bTBR=reed@google.com,robertphillips@google.com,mtklein@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1130333002
Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
These cover about 89% of draw calls from Blink SKPs,
and about 25% of draw calls from our GMs.
SkPicture handles:
- serialization and deserialization
- unique IDs
Everything else is left to the subclasses:
- playback(), cullRect()
- hasBitmap(), hasText(), suitableForGPU(), etc.
- LayerInfo / AccelData if applicable.
The time to record a 1-op picture improves a good chunk
(2 mallocs to 1), and the time to record a 0-op picture
greatly improves (2 mallocs to none):
picture_overhead_draw: 450ns -> 350ns
picture_overhead_nodraw: 300ns -> 90ns
BUG=skia:
Review URL: https://codereview.chromium.org/1112523006
Must have been we needed them to be weird (mutable, const setter) before.
It doesn't look like that's necessary now... we can just pass it to the
constructor.
BUG=skia:
Review URL: https://codereview.chromium.org/1112833003
This may be a small help to slimming paint:
picture_overhead_draw 1.25us -> 1.22us 0.98x
picture_overhead_nodraw 318ns -> 276ns 0.87x
It certainly cannot hurt performance.
BUG=chromium:470553
TBR=reed@google.com
No public API changes.
Review URL: https://codereview.chromium.org/1098183003
This saves "up to" 22 bytes per SkPicture.
Due to alignment, this reduces sizeof(SkPicture):
- from 88 to 72 bytes on Linux x64
- from 68 to 48 bytes on Android
(with Chrome's build settings)
It also somewhat simplifies the GPU veto logic.
BUG=skia:
[mtklein] No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1060863004
Chrome wants to call this more often, and it's quite slow today.
Seems like this could be clearer if SkPictureUtils::ApproxBytesUsed() were SkPicture::approxBytesUsed().
BUG=chromium:471873
Review URL: https://codereview.chromium.org/1090943004
If no one has read the picture's unique ID, there's no point invalidating it.
This is the same trick we pull with SkPixelRefs.
Before:
26M 1 1.49µs 1.6µs 1.77µs 6.25µs 42% picture_overhead_draw
13M 32 742ns 749ns 756ns 823ns 2% picture_overhead_nodraw
After:
26M 1 1.27µs 1.33µs 1.49µs 5.51µs 45% picture_overhead_draw
14M 43 677ns 680ns 681ns 701ns 1% picture_overhead_nodraw
BUG=skia:
Review URL: https://codereview.chromium.org/1061283002
All image compression currently uses (losseless) Deflate, not Jpeg.
All clients simply use SkDocument::CreatePDF(stream).
SampleApp and SkLua still use SkDocument::CreatePDF(path).
Review URL: https://codereview.chromium.org/935843007
SkStream is a stateful object, so it does not make sense for it to have
multiple owners. Make SkStream inherit directly from SkNoncopyable.
Update methods which previously called SkStream::ref() (e.g.
SkImageDecoder::buildTileIndex() and SkFrontBufferedStream::Create(),
which required the existing owners to call SkStream::unref()) to take
ownership of their SkStream parameters and delete when done (including
on failure).
Switch all SkAutoTUnref<SkStream>s to SkAutoTDelete<SkStream>s. In some
cases this means heap allocating streams that were previously stack
allocated.
Respect ownership rules of SkTypeface::CreateFromStream() and
SkImageDecoder::buildTileIndex().
Update the comments for exceptional methods which do not affect the
ownership of their SkStream parameters (e.g.
SkPicture::CreateFromStream() and SkTypeface::Deserialize()) to be
explicit about ownership.
Remove test_stream_life, which tested that buildTileIndex() behaved
correctly when SkStream was a ref counted object. The test does not
make sense now that it is not.
In SkPDFStream, remove the SkMemoryStream member. Instead of using it,
create a new SkMemoryStream to pass to fDataStream (which is now an
SkAutoTDelete).
Make other pdf rasterizers behave like SkPDFDocumentToBitmap.
SkPDFDocumentToBitmap delete the SkStream, so do the same in the
following pdf rasterizers:
SkPopplerRasterizePDF
SkNativeRasterizePDF
SkNoRasterizePDF
Requires a change to Android, which currently treats SkStreams as ref
counted objects.
Review URL: https://codereview.chromium.org/849103004
Gives more flexibility to the caller to decide whether to use the
encoded data returned by refEncodedData().
Provides an implementation that supports the old version of
SkPicture::serialize().
TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely
BUG=skia:3190
Review URL: https://codereview.chromium.org/784643002
Reason for revert:
Compilation is failing on some bots
Original issue's description:
> Replace EncodeBitmap with an interface.
>
> Gives more flexibility to the caller to decide whether to use the
> encoded data returned by refEncodedData().
>
> Provides an implementation that supports the old version of
> SkPicture::serialize().
>
> TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely
>
> BUG=skia:3190
>
> Committed: https://skia.googlesource.com/skia/+/0c4aba6edb9900c597359dfa49d3ce4a41bc5dd1TBR=reed@google.com,scroggo@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:3190
Review URL: https://codereview.chromium.org/787833002
Gives more flexibility to the caller to decide whether to use the
encoded data returned by refEncodedData().
Provides an implementation that supports the old version of
SkPicture::serialize().
TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely
BUG=skia:3190
Review URL: https://codereview.chromium.org/784643002
Restores type safety with all the same features.
(Also note, less code: 29 insertions, 50 deletions.)
BUG=skia:
Review URL: https://codereview.chromium.org/746553002
SkNVRefCnt is a variant of SkRefCnt that's Not Virtual, so weighs 4 bytes
instead of 8 or 16. There's only benefit to doing this if the deriving class
does not otherwise need a vtable, e.g. SkPicture.
I've stripped out some cruft from SkPicture, rearranged fields to pack tightly,
and added compile asserts for the sizes of SkPicture, SkRecord, and
SkVarAlloc.
BUG=skia:3144
Review URL: https://codereview.chromium.org/741793002
Idea:
1. in its mutable recording state, keep a table of drawables on the side, and store an index in the record list.
2. In "immediate-mode" draw, just call the clients drawable directly (need access to our private list to turn the stored index into a proc)
3. when we "snap", we replace the list of drawables with a list of (sub) pictures, and then during playback of the snapped picture, we invoke a private drawable which just calls "drawPicture" on the index'd subpicture.
Review URL: https://codereview.chromium.org/727363003
- move field declarations together and pack them a little tighter
- get rid of fData
- remove dead code in debugger, including unused SkPicturePlayback subclass
There are now no more long-lived SkPictureData! (Really, there never were,
but now we don't pretend to support them.)
BUG=skia:
No API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/725143002
This CL removes CollectLayers' reliance on having the top most picture (by removing the unused fPictureID member). This then allows making CollectLayers' API closer to that of SkRecordFillBounds in order to facilitate using them interchangeably.
Review URL: https://codereview.chromium.org/714533002
This will be a bit hairy to review.
The FillBounds and CollectLayers code has diverged significantly resulting in the rendering path seeing different bounds than the hoisting path. This CL merges the FillBounds changes into CollectLayers. A follow on CL will, hopefully, find a way to layer CollectLayers on top of FillBounds.
The only code in CollectLayers that is different from FillBounds is bracketed by "LAYER HOISTING" comments.
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/685263004
This is basically how blink uses the filter. Currently, I can't use it for "ShadowOnly" mode with the filter at all, but instead of copying the code and risking to have the codepaths diverge, I'm simply going to add the option here.
BUG=skia:
Review URL: https://codereview.chromium.org/646213004
This removes:
1) ability to record old pictures with SkPictureRecorder;
2) a couple tests specific to the old backend.
The functionality of DEPRECATED_beginRecording() now lives in
(private) SkPicture::Backport(), which is the only place we
need it now.
BUG=skia:
TBR=reed@google.com
Review URL: https://codereview.chromium.org/618303002
Having hoisted layers from different pictures invalidates the assumptions of the old GrReplacements object. This is fixed by switching to a SkTDynamicHash-based back-end.
Sub-picture-layers also require that the replacement drawing occur for the sub-pictures too. The ReplaceDraw object is added to make this happen and limit the replacement lookup to saveLayer draw commands.
This is split out of (Fix sub-picture layer rendering bugs - https://codereview.chromium.org/597293002/).
BUG=skia:2315
Review URL: https://codereview.chromium.org/607763008
Feature-wise, this removes:
1) BBH support;
2) peephole optimizations;
3) record-time text op specializations;
4) the guarantee that SkPaints are flattened.
This deletes the optimizations GM, which only exists to test the peepholes of
the old backend. SkRecord optimizations are unit tested, and if that ever fails we
can think about adding another GM like this, but they're different enough we'd
want to start from scratch anyway.
We need to keep the code that plays back the specialized text ops around for
a while for compatibility with existing .SKPs that have those ops recorded.
BUG=skia:
CQ_EXTRA_TRYBOTS=tryserver.skia:Canary-Chrome-Ubuntu13.10-Ninja-x86_64-ToT-Trybot
R=robertphillips@google.com, reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/617953002
For now this only creates a degenerate bounding box hierarchy where all ops
just have maximal bounds. I will flesh out FillBounds in future CL(s).
Not quite sure why QuadTree and TileGrid aren't drawing right---haven't even
looked at the diffs yet---so I've disabled those test modes for now. RTree
seems fine, so that'll at least get us coverage for all this new plumbing.
BUG=skia:
R=robertphillips@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/454123003
Add a unique ID to SkImageFilter, and use it as part
of a persistent cache of image-filtered results. This is used for
caching frame-to-frame coherent filters.
We also keep track of which filter subtrees do not reference the
src input, and use a GenID of zero for the src input in that case.
That way, subtrees which are not dependent on the filter input can be
cached independently of it.
This gives approximately a 4X speedup on
letmespellitoutforyou.com/samples/svg/filter_terrain.svg on Z620
and Nexus10. The cache key consists of the uniqueID of the filter, the
clip bounds, the CTM and the genID of the input bitmap.
Since this does not yet handle the case where the input primitives
(and part of the resulting filter tree) are unchanged, we have
to keep around the external cache for that painting case.
When the work to cache unchanging input primitives is done, the
old cache can be removed, and the new UniqueIDCache will be renamed
to Cache.
R=bsalomon@google.com, mtklein@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/414483003
Reason for revert:
Going to try to just remove the many-at-once clone interface
Original issue's description:
> Add alternate SkPicture::clone
>
> This adds an alternate version of SkPicture::clone for two reasons:
>
> 1) Chromium uses the SkPicture copy constructor to unpack the pictures from the old-style clone interface (and I would like to remove the copy ctor)
>
> 2) This is part of the long term plan to wean Chrome off of cloning. Once pictures are thread safe we will switch the new SkPicture::clone call to just return 'this'. From there it is a small step to removing clone entirely.
>
> Note that the two versions of clone() is temporary. Once this is landed (and rolled) I will land a Chrome-side patch to remove their use of the old interface (Use new SkPicture::clone interface - https://codereview.chromium.org/380323002/)
>
> Committed: https://skia.googlesource.com/skia/+/e372e78223a8ce916d276d6e0420d552fb0267e9R=mtklein@google.com, reed@google.comTBR=mtklein@google.com, reed@google.com
NOTREECHECKS=true
NOTRY=true
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/386933004
This adds an alternate version of SkPicture::clone for two reasons:
1) Chromium uses the SkPicture copy constructor to unpack the pictures from the old-style clone interface (and I would like to remove the copy ctor)
2) This is part of the long term plan to wean Chrome off of cloning. Once pictures are thread safe we will switch the new SkPicture::clone call to just return 'this'. From there it is a small step to removing clone entirely.
Note that the two versions of clone() is temporary. Once this is landed (and rolled) I will land a Chrome-side patch to remove their use of the old interface (Use new SkPicture::clone interface - https://codereview.chromium.org/380323002/)
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/381193002
This CL begins setting up the SkPicturePlayback split by simplifying the class and componentizing it a bit. It:
fuses SkPictureData::OperationList into SkPicture::OperationList
adds a handleOp method to SkPicturePlayback that can be reused by derived classes
removes a couple debugging tools (ENABLE_TIME_DRAW & SPEW_CLIP_SKIPPING)
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/378703002
This splits the playback functionality out of SkPictureData. The old SkPictureData::draw method is pulled out along
with its supporting functions as verbatim as possible. Some follow on CLs will be required to:
re-enable profiling in the debugger (and remove the vestiges of SkTimedPicture)
re-enable display of command offsets in the picture (this should probably wait until we've switched to SkRecord though)
Clean up CachedOperationList (maybe fuse with SkPicture::OperationList)
Split SkPicturePlayback into a base class and two derived classes
Implement parallel version of GatherGPUInfo for SkRecord
Landing this is blocked on removing Android's use of the abortPlayback entry point.
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/377623002
- support fRecord in copy constructor
- support SkDrawPictureCallback
Moved SkDrawPictureCallback to its own header so
SkRecordDraw can include it without pulling in all of
SkPicture.
Adding an SkAutoSaveRestore to SkRecordDraw was the easiest
way to match the balance guarantees of the callback, and
probably not a bad idea in general. Updated its tests.
BUG=skia:
R=robertphillips@google.com
Review URL: https://codereview.chromium.org/349973008
I've tagged all the functions in SkPicture.cpp is // fRecord TODO or // fRecord
OK, depending on whether or not they're totally broken when used from an
SkRecord-based picture. Obviously next steps are to eliminate all the TODOs,
then clean up the notes.
I converted SkPicture over to smart pointers too. It's particularly helpful
that the smart pointers initialize to NULL by default.
For now I've got all the SkRecord-based code jammed in at the bottom of the file. I figure it'll help me keep things straight for a bit, then we can rearrange later.
BUG=skia:
R=robertphillips@google.com
Review URL: https://codereview.chromium.org/333823007
This CL improves the separation of the SkPicture and SkPictureRecord classes. It delays creation of the SkPicture (in SkPictureRecorder) until recording is actually completed. To accomplish this the SkRecord-derived classes now get SkPathHeap and SkPictureContentInfo members that are absorbed by the SkPicture when it is constructed.
As an ancillary change, this CL also moves the SkPictureContentInfo object from SkPicture to SkPicturePlayback. This is intended to centralize all the data in the SkPicturePlayback object.
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/324293004
This is split out of https://codereview.chromium.org/316063005/ for clarity. Keeping in mind that SkPicture::FakeEndRecording is now only called from SkPictureRecorder, its deepCopy parameter is no longer necessary. This is b.c., given the new Picture recording semantics (where SkPictures can no longer be actively recording), cloning for thread safety only happens when an SkPicturePlayback has already been allocated (i.e., it happens in the SkPicturePlayback copy constructor.
R=scroggo@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/324093003
My goal here was to add a single location where we could patch up the created PicturePlayback. Unfortunately, the complexity of the recording process (e.g., the BBH) makes this quite complex.
I will investigate altering the behavior of SkPicturePlayback to account for a potentially unbalanced set of saves/saveLayers.
R=reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/283333007
git-svn-id: http://skia.googlecode.com/svn/trunk@14773 2bbb7eff-a529-9590-31e7-b0007b416f81
