Implement webview.captureVisibleRegion()

content/browser/frame_host/render_widget_host_view_child_frame.h

Index: content/browser/frame_host/render_widget_host_view_child_frame.h
diff --git a/content/browser/frame_host/render_widget_host_view_child_frame.h b/content/browser/frame_host/render_widget_host_view_child_frame.h
index 4bacd21f3d8aa0a7d73a590537f9c03b58e4c085..f8fcdb877d60f9f6fd8afe89950e2627f1ba348e 100644
--- a/content/browser/frame_host/render_widget_host_view_child_frame.h
+++ b/content/browser/frame_host/render_widget_host_view_child_frame.h
@@ -8,8 +8,10 @@
 #include <stddef.h>
 #include <stdint.h>
 
+#include <deque>
 #include <vector>
 
+#include "base/callback.h"
 #include "base/macros.h"
 #include "base/memory/scoped_ptr.h"
 #include "build/build_config.h"
@@ -58,6 +60,12 @@ class CONTENT_EXPORT RenderWidgetHostViewChildFrame
     frame_connector_ = frame_connector;
   }
 
+  // This functions registers single-use callbacks that want to be notified when
+  // the next frame is drawn. Once called, the callback pointer is released.
+  // TODO(wjmaclean): We should consider making this available in other view
+  // types, such as RenderWidgetHostViewAura.

[ncarter (slow), 2016/01/27 21:08:25]

This seems fairly similar in purpose to RenderWidgetHostViewFrameSubscriber,
though the abilities of that interface is currently narrowly scoped to what
WebContentsVideoCaptureDevice needs (only one subscriber is supported, it
assumes a stream of frames, and it assumes you want things like YV12 that are
appropriate for dumping into a video encode).

[wjmaclean, 2016/01/27 21:28:01]

Are you suggesting we re-write RenderWidgetHostViewFrameSubscriber then to be
more general?

[ncarter (slow), 2016/01/28 20:49:58]

My main intent was to call attention to the RenderWidgetHostViewFrameSubscriber
methods in RWHVBase, which seems like it has some level of functional overlap
with this -- which I thought was potentially worth mentioning in the TODO.

Having done a little more thinking, I am now wondering whether an even better
long-term approach might be for RenderWidgetHostViewFrameSubscriber to be
eliminated, and have WebContentsVideoCaptureDevice's FrameSubscriber be
implemented in terms of something simpler like RegisterFrameDrawnCallback.
RenderWidgetHostViewFrameSubscriber originally had some really gnarly threading
behaviors, and had to be driven substantially differently between platforms. I
don't think any of these are concerns anymore: DelegatedFrameHost drives the
FrameSubscriber on all platforms, and WCVCD's FrameSubscriber is in content (and
thus can do content-impl things), so if we provided some kind of hook at
compositor-swap time (i.e. RegisterFrameDrawnCallback), maybe the rest of the
FrameSubscriber-specific behavior could be moved out of DelegatedFrameHost.

Anyhow: the upshot of this is that I'm on board with RWHVBase having a
RegisterFrameDrawnCallback.

[miu, 2016/02/04 20:19:11]

Agreed.  I have it on my roadmap this year to do some significant refactoring in
this area.  In particular, FrameSubscriber was solving problems in the
"pre-Uber-Compositor world" and has suffered some rather weird code factoring
issues over the past 2+ years.  In one case (that I was not aware of at the
time), someone threw up their arms and just copy-and-pasted a bunch of code from
DelegatedFrameHost in order to implement screen capture on CrOS.  That's not
good.

So, for the future, I think it makes sense for the Compositor to provide some
kind of "frame observer" interface instead of the RenderWidgetHostView*
providing a "frame subscriber" interface.  I have a number of ideas that I plan
to prototype-out before proposing a new design.
I'm not sure it will stay that way for long, but I don't see this as a bad idea
now, nor would it seem to make my future refactoring efforts any more difficult.

+  void RegisterFrameDrawnCallback(scoped_ptr<base::Closure> callback);

[ncarter (slow), 2016/01/27 21:08:25]

In the webview case, is there really necessarily a "frame drawn" event in the
RWHVChildFrame for every visible change to the pixel content (I'm thinking about
when there are oopifs or, I dunno, flash or something, that could cause an
additional delegated layer under the current one)?

If these were OOPIFs, then in the A(B(C)) case, if we're capturing B, will
reading from B's RWHVChildFrame actually include the pixel content from C?

[wjmaclean, 2016/01/27 21:28:01]

I'm not entirely sure, though I suspect the surface for B would include it. It's
easy enough to test.

[ncarter (slow), 2016/01/28 20:49:58]

OK.

[miu, 2016/02/04 20:19:10]

My understanding here is that the Compositor will execute a "copy request on
layer B" on the result from drawing "B(C)".  In other words, I'd expect to see
the pixels for B and C.

+
   // RenderWidgetHostView implementation.
   void InitAsChild(gfx::NativeView parent_view) override;
   RenderWidgetHost* GetRenderWidgetHost() const override;
@@ -206,6 +214,15 @@ class CONTENT_EXPORT RenderWidgetHostViewChildFrame
   }
 
  private:
+  void SubmitSurfaceCopyRequest(const gfx::Rect& src_subrect,
+                                const gfx::Size& dst_size,
+                                const ReadbackRequestCallback& callback,
+                                const SkColorType preferred_color_type);
+
+  using FrameDrawnCallbackList = std::deque<scoped_ptr<base::Closure>>;
+  // Since frame-drawn callbacks are "fire once", we use std::deque to make
+  // it convenient to swap() when processing the list.
+  FrameDrawnCallbackList frame_drawn_callbacks_;
   base::WeakPtrFactory<RenderWidgetHostViewChildFrame> weak_factory_;
   DISALLOW_COPY_AND_ASSIGN(RenderWidgetHostViewChildFrame);
 };