DevTools: add instrumentation for deferred canvas rasterization

Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp

Index: Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp
diff --git a/Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp b/Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp
index 8dc281fa16fec3e68dbf961c6abcfa40d73e32c0..6959990299972a47d59f3993a4c70821983e0c9e 100644
--- a/Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp
+++ b/Source/core/platform/graphics/chromium/Canvas2DLayerBridge.cpp
@@ -30,6 +30,7 @@
 #include "GrContext.h"
 #include "SkDevice.h"
 #include "SkSurface.h"
+#include "core/platform/PlatformInstrumentation.h"
 #include "core/platform/chromium/TraceEvent.h"
 #include "core/platform/graphics/GraphicsContext3D.h"
 #include "core/platform/graphics/GraphicsLayer.h"
@@ -194,6 +195,7 @@ bool Canvas2DLayerBridge::prepareMailbox(WebKit::WebExternalTextureMailbox* outM
     // Early exit if canvas was not drawn to since last prepareMailbox
     if (image->uniqueID() == m_lastImageId)
         return false;
+    PlatformInstrumentation::willRasterizeCanvas();

[Justin Novosad, 2013/06/26 21:06:49]

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:50]

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.

     m_lastImageId = image->uniqueID();
 
     mailboxInfo = createMailboxInfo();
@@ -224,6 +226,7 @@ bool Canvas2DLayerBridge::prepareMailbox(WebKit::WebExternalTextureMailbox* outM
     m_context->grContext()->resetContext();
 
     *outMailbox = mailboxInfo->m_mailbox;
+    PlatformInstrumentation::didRasterizeCanvas();
     return true;
 #else
     ASSERT_NOT_REACHED();