- 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'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
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
