cc: Async readback.

cc/output/gl_renderer.cc

Index: cc/output/gl_renderer.cc
diff --git a/cc/output/gl_renderer.cc b/cc/output/gl_renderer.cc
index e822023aed4d354856b9e80f8a87a3bff353c6fa..9ff3853a9a50b075413e08fc164f8a2ec8a80c67 100644
--- a/cc/output/gl_renderer.cc
+++ b/cc/output/gl_renderer.cc
@@ -1763,6 +1763,19 @@ void GLRenderer::EnsureScissorTestDisabled() {
   is_scissor_enabled_ = false;
 }
 
+void GLRenderer::CopyCurrentRenderPassToBitmap(DrawingFrame* frame,
+                                               SkBitmap* bitmap) {
+  gfx::Size render_pass_size = frame->current_render_pass->output_rect.size();
+  bitmap->setConfig(SkBitmap::kARGB_8888_Config,
+                    render_pass_size.width(),
+                    render_pass_size.height());
+  if (bitmap->allocPixels()) {
+    bitmap->lockPixels();
+    GetFramebufferPixels(bitmap->getPixels(), gfx::Rect(render_pass_size));

[piman, 2013/04/25 02:13:52]

How hard would it be to add the flexibility, and asyncness of
GLHelper::CopyTextureToImpl::CropScaleReadbackAndCleanTexture ?

GPU scale is needed on at least some chrome OS devices (Alex at least? Probably
Pixel too) to avoid hundreds of ms jank in the GPU process - reading back the
entire buffer is just too much.
The asyncness is to avoid janking the compositor thread itself, because
readPixels is essentially a glFinish, so it has to wait for GPU process
completion, and it breaks pipelining (the tab capture guys want to do this every
frame).

[danakj, 2013/04/25 18:39:15]

Flexibility is fine, pass around a struct with more params than a callback
alone. I'll do that in a separate followup with tests.
The asyncyness I need to understand better, but also seems totally fine. Also
will do as a followup.

+    bitmap->unlockPixels();
+  }
+}
+
 void GLRenderer::ToGLMatrix(float* gl_matrix, const gfx::Transform& transform) {
   transform.matrix().asColMajorf(gl_matrix);
 }