add SkDrawPictureCallback optional parameter to drawPicture(), which can abort the picture drawing.

add SkDrawPictureCallback optional parameter to drawPicture(), which can abort the picture drawing.

R=bsalomon@google.com

Committed: https://code.google.com/p/skia/source/detail?r=9197

[reed1, 2013-05-16 14:57:40]

Motivated by chrome's desire to playback pictures into their "analysis canvas"
subclass, which computes stats. They believe that often they will have finished
their analysis (e.g. is this picture simple?) early on, and don't want to pay
the cost of continuing playback to the end.

reviewers:

1. are we ok with this feature?
2. is it safe/well-defined for all our backends (I assume it is ignored on some)
3. are there threading or life-cycle issues with this object (I hope we never
have to retain it)

There are other approaches we could consider:

1. canvas.fAbortDrawing, which could be set by the receiving canvas, and
picture-playback could "check" that field periodically. This seems
lighter-weight, but also makes the canvas itself stateful (ick).

2. virtual bool canvas::abortPictureDrawing() -- same as a field, but would
require the client to subclass canvas to pop in their own impl. Also it would
mean a virtual call each time in playback (even if there is no interesting
override)

3. other?

[reed1, 2013-05-16 14:59:50]

crazy thought: what if they just set their canvas' clip to empty when they're
"done". I wonder if our quickReject (and jumps to matching restores) would be
enough of an acceleration for them....?

[robertphillips, 2013-05-16 15:04:23]

https://codereview.chromium.org/14598023/diff/1/include/core/SkPicture.h
File include/core/SkPicture.h (right):

https://codereview.chromium.org/14598023/diff/1/include/core/SkPicture.h#newc...
include/core/SkPicture.h:154: @param canvas the canvas receiving the drawing
commands.
// @param callback optional callback to abort drawing

https://codereview.chromium.org/14598023/diff/1/src/core/SkPicturePlayback.cpp
File src/core/SkPicturePlayback.cpp (right):

https://codereview.chromium.org/14598023/diff/1/src/core/SkPicturePlayback.cp...
src/core/SkPicturePlayback.cpp:720: #ifdef SK_BUILD_FOR_ANDROID
can this be folded into the new system?

[bsalomon, 2013-05-16 18:23:18]

On 2013/05/16 14:59:50, reed1 wrote:
> crazy thought: what if they just set their canvas' clip to empty when they're
> "done". I wonder if our quickReject (and jumps to matching restores) would be
> enough of an acceleration for them....?

That seems too hacky to me. It may work now but not in the future.

[vangelis, 2013-05-17 00:43:53]

Thanks for putting this together. To clarify the use-case, we'll early out the
analysis (in our case detecting solid color tiles) if we see any non-solid draws
(e.g. text, paths, etc). 

Over time, this could be useful for the isGanesh-able test too.

I have no objections for the API design.

[reed1, 2013-05-20 16:44:14]

PTAL -- I don't have any ideas to make it better/simpler/clearer. Are we good to
go, or does someone want to rename/rethink this?

[bsalomon, 2013-05-20 16:53:57]

On 2013/05/20 16:44:14, reed1 wrote:
> PTAL -- I don't have any ideas to make it better/simpler/clearer. Are we good
to
> go, or does someone want to rename/rethink this?

lgtm

[reed1, 2013-05-20 17:02:47]

Committed patchset #3 manually as r9197 (presubmit successful).

[robertphillips, 2013-05-20 17:05:19]

lgtm. Unit test?

https://codereview.chromium.org/14598023/diff/11001/include/core/SkPicture.h
File include/core/SkPicture.h (right):

https://codereview.chromium.org/14598023/diff/11001/include/core/SkPicture.h#...
include/core/SkPicture.h:154: @param canvas the canvas receiving the drawing
commands.
document 'callback' parameter?