bench_pictures now has an option for benchmarking record time.

bench_pictures now has an option for benchmarking record time.

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

[nduca, 2012-07-13 07:18:44]

How do we validate the record times coming out of this are comparable to the
record times coming from a real C++ source?

[nduca, 2012-07-13 07:19:52]

On 2012/07/13 07:18:44, nduca wrote:
> How do we validate the record times coming out of this are comparable to the
> record times coming from a real C++ source?

Is this a matter of

  bench_pictures.recordTime  - replayer.drawPictureToNullCanvas()?

[keyar, 2012-07-13 17:13:31]

On 2012/07/13 07:19:52, nduca wrote:
> On 2012/07/13 07:18:44, nduca wrote:
> > How do we validate the record times coming out of this are comparable to the
> > record times coming from a real C++ source?
> 
> Is this a matter of
> 
>   bench_pictures.recordTime  - replayer.drawPictureToNullCanvas()?

So, I don't quite understand the issue. Are we worried that a program with calls
like

SkPicture recorder;
recordingCanvas* = recorder.beginRecording();

recordingCanvas->command();
recordingCanvas->command();

would have different timings from
SkPicture recorder;
recordingCanvas* = recorder.beginRecording();

recordingCanvas->drawPicture(somePicture);

where somePicture is the equivalent of the two recordingCanvas->commands() from
above?

[nduca, 2012-07-13 20:03:36]

Yep. Presumably there's some playback overhead in there that the raw program
won't have? How bad is it?

[junov1, 2012-07-13 21:23:31]

On 2012/07/13 20:03:36, nduca wrote:
> Yep. Presumably there's some playback overhead in there that the raw program
> won't have? How bad is it?

The playback overhead is very lightweight.  All objects required for playback
are pre-unflattened. So all playback does is execute bytecode. See
SkPicturePlayback::draw

[nduca, 2012-07-14 00:37:53]

Cool. Well, LGTM. Might be good to see another test that measures the cost of
playback into a null canvas to verify that assertion.