Define frame subscription interface and implementation on Mac

content/port/browser/render_widget_host_view_port.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CONTENT_PORT_BROWSER_RENDER_WIDGET_HOST_VIEW_PORT_H_
 #define CONTENT_PORT_BROWSER_RENDER_WIDGET_HOST_VIEW_PORT_H_
 
 #include "base/callback.h"
 #include "base/process_util.h"
 #include "base/string16.h"
@@ skipping 24 matching lines @@
 struct WebPluginGeometry;
 }
 }
 
 namespace WebKit {
 struct WebScreenInfo;
 }
 
 namespace content {
 class BackingStore;
+class RenderWidgetHostViewFrameSubscriber;
 class SmoothScrollGesture;
 struct NativeWebKeyboardEvent;
 
 // This is the larger RenderWidgetHostView interface exposed only
 // within content/ and to embedders looking to port to new platforms.
 // RenderWidgetHostView class hierarchy described in render_widget_host_view.h.
 class CONTENT_EXPORT RenderWidgetHostViewPort : public RenderWidgetHostView {
  public:
   virtual ~RenderWidgetHostViewPort() {}
 
@@ skipping 126 matching lines @@
       const base::Callback<void(bool)>& callback) = 0;
 
   // Returns true if CopyFromCompositingSurfaceToVideoFrame() is likely to
   // succeed.
   //
   // TODO(nick): When VideoFrame copies are broadly implemented, this method
   // should be renamed to HasCompositingSurface(), or unified with
   // IsSurfaceAvailableForCopy() and HasAcceleratedSurface().
   virtual bool CanCopyToVideoFrame() const = 0;
 
+  // Begin subscribing for presentation events and captured frames.

[ncarter (slow), 2013/02/16 02:45:22]

My familiarity with the render_(view|widget).* code is still far from expert,
but right now this interface feels wrongly factored to me. I don't have a better
solution, but I'll offer some problems I see.

+  // |subscriber| is now owned by this object, it will be called on the
+  // presentation thread which might not be the UI thread.

[ncarter (slow), 2013/02/16 02:45:22]

It feels somewhat unstructured, that the code to interact with the
FrameSubscriber is going to have to be implemented on every platform, and that
the threading behavior is going to be different. Are we 100% sure that we really
can't make the "should capture frame being presented" decision on the UI thread,
and forward the decision to present thread?

[Alpha Left Google, 2013/02/20 21:34:50]

No we can't guarantee that we can make the decision on the UI thread. In fact
even doing it on the UI thread is not the best. The best to do is to let the
amount of resources to do rate limiting and in this case the limiting factor is
on the IO thread for shared memory.

I envision it will look like this:

[ Presentation thread]  Presenter -> pull frames synchronously from -> Frame
Subscriber

[ UI thread ] Frame Subscriber -> pull frames asynchronously from -> WCVCD
                   WCVCD -> pull frames asynchronously from ->
VideoCaptureManager

[ IO Thread ] VideoCaptureManager -> pull frames synchronously from -> Shared
memory

I imagine FrameSubscriber to be a simple implementation that has:
1. An initial set of frames to fill in
2. A scoped_refptr to WCVCD and MessageLoopProxy where WCVCD lives

Once FrameSubscriber is constructed with above items the ownership is
transferred to the presenter, it is then never called on threads other than the
presentation thread. Everything is asynchronous except for the end points.

+  //
+  // TODO(hclam): Implement this API on all platforms.

[ncarter (slow), 2013/02/16 02:45:22]

How does the user of this mechanism know whether BeginFrameSubscription is
supported on his platform?

[Alpha Left Google, 2013/02/20 21:34:50]

I added CanSubscribeFrame().

+  virtual void BeginFrameSubscription(
+      RenderWidgetHostViewFrameSubscriber* subscriber) {}
+
+  // End subscribing for frame presentation events. |subscriber| will be
+  // deleted after this call.
+  virtual void EndFrameSubscription(
+      RenderWidgetHostViewFrameSubscriber* subscriber) {}

[ncarter (slow), 2013/02/16 02:45:22]

If ownership of |subscriber| passes to the RWHVP, then isn't it impossible for
the caller to retain the subscriber pointer, to pass into this method?

[Alpha Left Google, 2013/02/20 21:34:50]

The ownership is transferred but WCVCD should keep a const FrameSubscriber*
const for terminating the subscription. It uses as a handle but should be never
be called by WCVCD again. I'm open to suggestions if you think there's something
better can be done here.

+
   // Called when accelerated compositing state changes.
   virtual void OnAcceleratedCompositingStateChange() = 0;
   // |params.window| and |params.surface_id| indicate which accelerated
   // surface's buffers swapped. |params.renderer_id| and |params.route_id|
   // are used to formulate a reply to the GPU process to prevent it from getting
   // too far ahead. They may all be zero, in which case no flow control is
   // enforced; this case is currently used for accelerated plugins.
   virtual void AcceleratedSurfaceBuffersSwapped(
       const GpuHostMsg_AcceleratedSurfaceBuffersSwapped_Params& params_in_pixel,
       int gpu_host_id) = 0;
@@ skipping 108 matching lines @@
   virtual BrowserAccessibilityManager*
       GetBrowserAccessibilityManager() const = 0;
   virtual void OnAccessibilityNotifications(
       const std::vector<AccessibilityHostMsg_NotificationParams>& params) {
   }
 };
 
 }  // namespace content
 
 #endif  // CONTENT_PORT_BROWSER_RENDER_WIDGET_HOST_VIEW_PORT_H_