DevTools: add instrumentation for deferred canvas rasterization

DevTools: add instrumentation for deferred canvas rasterization

- expose instrumentation cookie through WebDevToolsAgent, so that
    embedder-side trace events may be associated with particular
    inspected page;
- instrument Canvas2DLayerBridge
- process UpdateLayer and RasterizeCanvas events in TimelineTraceEventProcessor

Related chromium-side change: https://codereview.chromium.org/16848010/

BUG=244505

[caseq, 2013-06-17 17:59:37]

This is an alternative approach to what was done in
https://codereview.chromium.org/16896007/

[caseq, 2013-06-26 12:49:22]

Get layer tree id through to timeline agent instead of plumbing page identity to
layer tree host.

[Justin Novosad, 2013-06-26 21:06:48]

https://codereview.chromium.org/16878004/diff/7001/Source/core/platform/graph...
File Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp (right):

https://codereview.chromium.org/16878004/diff/7001/Source/core/platform/graph...
Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp:198:
PlatformInstrumentation::willRasterizeCanvas();
This will only measure deferred canvas rendering in the context of a layer
update.  There are other circumstance where deferred canvas rendering can get
triggered (Deferal buffer is full, JS command that triggers a synchronous
readback, canvas-to-canvas copy using drawImage).  If we are only concerned with
filling the gap in the timeline, then this is OK.  However if we want to
accurately report time spent executing deferred canvas draw operations, we
should be calling willRasterizeCanvas in prepareForDraw, and we should call
didRasterizeCanvas in flushedDrawCommands.  Also, if we do that, we<d have to
change the implementation of skippedPendingDrawCommands so that it no longer
calls flushedDrawCommands, because we don't want it to call didRasterizeCanvas.

[caseq, 2013-06-27 17:03:49]

https://codereview.chromium.org/16878004/diff/7001/Source/core/platform/graph...
File Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp (right):

https://codereview.chromium.org/16878004/diff/7001/Source/core/platform/graph...
Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp:198:
PlatformInstrumentation::willRasterizeCanvas();
Thanks, Justin, it's very helpful! I was originally aiming at instrumenting just
the part that the main thread was being blocked on a sync gl call, since we
don't yet have a good way to show async stuff that happens on GPU -- so it
basically only worked to fill the timeline gap. Turns out the fact that we were
doing the sync call here was a bug on its own (fixed by piman at r152657), so my
original approach is no longer relevant here (we just block elsewhere). So it
looks like we need properly expose it as an async/background event for canvas
flush, which will likely require a bit more work on the timeline side.

[Justin Novosad, 2013-06-27 18:46:58]

On 2013/06/27 17:03:49, caseq wrote:
>
https://codereview.chromium.org/16878004/diff/7001/Source/core/platform/graph...
> File Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp (right):
> 
>
https://codereview.chromium.org/16878004/diff/7001/Source/core/platform/graph...
> Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp:198:
> PlatformInstrumentation::willRasterizeCanvas();
> Thanks, Justin, it's very helpful! I was originally aiming at instrumenting
just
> the part that the main thread was being blocked on a sync gl call, since we
> don't yet have a good way to show async stuff that happens on GPU -- so it
> basically only worked to fill the timeline gap. Turns out the fact that we
were
> doing the sync call here was a bug on its own (fixed by piman at r152657), so
my
> original approach is no longer relevant here (we just block elsewhere). So it
> looks like we need properly expose it as an async/background event for canvas
> flush, which will likely require a bit more work on the timeline side.

I think it is still relevant to track the time spent to set up and send commands
to the GPU (SkDeferredCanvas flush), which is synchronous on the main thread of
the renderer process

[pfeldman, 2013-08-26 11:38:30]

Is this still relevant?

[nduca, 2013-08-26 19:26:53]

Deferred canvas flushing is a big performance cost so we definitely want to make
sure its captured. I can't recall if this is the correct route to do this
however. I think this is @junov territory to say.

[Justin Novosad, 2013-08-26 19:39:02]

On 2013/08/26 19:26:53, nduca wrote:
> Deferred canvas flushing is a big performance cost so we definitely want to
make
> sure its captured. I can't recall if this is the correct route to do this
> however. I think this is @junov territory to say.

IIRC, Andrey had competing implementations.  Is this the abandoned one?

[pfeldman, 2013-08-30 09:19:28]

Closing for no response from caseq@.

[caseq, 2013-08-30 09:22:26]

On 2013/08/30 09:19:28, pfeldman wrote:
> Closing for no response from caseq@.

Sorry about the delay. I'm working on the alternative approach, this one turned
to be instrumenting the wrong part of the code.