Define frame subscription interface and implementation on Mac

content/port/browser/render_widget_host_view_frame_subscriber.h

Index: content/port/browser/render_widget_host_view_frame_subscriber.h
diff --git a/content/port/browser/render_widget_host_view_frame_subscriber.h b/content/port/browser/render_widget_host_view_frame_subscriber.h
new file mode 100644
index 0000000000000000000000000000000000000000..c3c21334e6def3c055f0f42f114b3fb7c9c95df4
--- /dev/null
+++ b/content/port/browser/render_widget_host_view_frame_subscriber.h
@@ -0,0 +1,75 @@
+// 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_FRAME_SUBSCRIBER_H_
+#define CONTENT_PORT_BROWSER_RENDER_WIDGET_HOST_VIEW_FRAME_SUBSCRIBER_H_
+
+#include "base/callback.h"
+#include "base/time.h"
+
+namespace gfx {
+class Rect;
+class Size;
+}  // namespace gfx
+
+namespace media {
+class VideoFrame;
+}  // namespace media
+
+namespace content {
+
+// Defines an interface for listening to events of frame presentation and to
+// instruct the platform layer (i.e. RenderWidgetHostViewPort) to copy a frame.
+//
+// Further processing is possible (e.g. scale and clip) through this
+// interface. See ShouldCaptureFrame() for details.
+//
+// Objects of this class live on the UI thread.

[piman, 2013/02/22 20:45:47]

How will this work on non-aura windows?

[Alpha Left Google, 2013/02/22 21:05:38]

Present has to go through UI thread somehow, we plan to plant the output
VideoFrame here:
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/re...

Such that UI thread RWHVP can decide whether to have presenter do the copy.

[piman, 2013/02/22 21:18:54]

No, it doesn't in the general case. On windows, the UI thread cannot be involved
in the presentation path from the renderer - it'd cause deadlocks.
That path is only taken to patch OS-level damage (e.g. window exposure), and not
generally involved in the renderer path.
Given the above, I don't think so...

+class RenderWidgetHostViewFrameSubscriber {
+ public:
+  virtual ~RenderWidgetHostViewFrameSubscriber() {}
+
+  // Called when a captured frame is available or the frame is no longer
+  // needed by the platform layer.
+  //
+  // If |frame_captured| is true then frame provided contains valid content and
+  // |timestamp| is the time when the frame was painted.
+  //
+  // If |frame_captured| is false then the content in frame provided is
+  // invalid. There was an error during the process of frame capture or the
+  // platform layer is shutting down. |timestamp| is also invalid in this case.
+  typedef base::Callback<void(
+      bool /* frame_captured */,
+      base::Time /* timestamp */)> DeliverFrameCallback;
+
+  // Called when a new frame is going to be presented. Implementation can
+  // decide whether the current frame should be captured or not. Frame size
+  // is given such that implementor can choose to apply scaling and clipping
+  // to the frame captured. |src_size| is the size of the frame going to be
+  // presented, |src_subrect| will be set to choose clipping rectangle and
+  // |dst_subrect| will be set to choose destination rectangle.
+  //
+  // Return true if the current frame should be captured. If so, |storage|
+  // should will be set to hold an appropriately sized and allocated buffer
+  // into which to copy the frame.
+  //
+  // Destination format is determined by |storage|, currently only
+  // media::VideoFrame::YV12 is supported. Platform layer will perform color
+  // space conversion if needed.

[piman, 2013/02/22 20:45:47]

So, that leaves the RWHV responsible for doing the readback. In our discussions,
for the Aura case I thought we settled on passing a texture to the receiving
renderer, that would do the readback.

The former adds quite a bit of complexity to the compositor, since it then needs
to babysit the asynchronous readback, and deal with the platform fallback.

We can chat more, but is it conceivable that for Aura we'd use the
NATIVE_TEXTURE format (or something like that)?

[Alpha Left Google, 2013/02/22 21:05:38]

Without our team we went back and forth with this. The conclusion is that for
Aura we should try to use the existing architecture, i.e. browser process do the
read back and hand it off to the extension renderer. This will have an extra
memcpy but simplify a whole lot as the first attempt.

[piman, 2013/02/22 21:18:54]

"simplyfy" = maybe for you, but really it means moving the complexity to another
place.

+  //
+  // When the frame is available |callback| will be called. It is up to the
+  // platform layer to decide when to deliver a captured frame.
+  //
+  // Return false if the current frame should not be captured.
+  virtual bool ShouldCaptureFrame(
+      const gfx::Size& src_size,
+      gfx::Rect* src_subrect,
+      gfx::Rect* dst_subrect,

[piman, 2013/02/22 20:45:47]

do we really need dst_subrect, or simply dst_size? Or even base it on storage's
size ?

[Alpha Left Google, 2013/02/22 21:05:38]

Yes because of letter boxing. Implementation of FrameSubscriber can implement
letter boxing logic and RWHVP doesn't have to know this.

[piman, 2013/02/22 21:18:54]

Not sure I understand... why would we want to carry around and send over the
network a bunch of zeros? Can't letter-boxing be handled on the presentation
path?

+      scoped_refptr<media::VideoFrame>* storage,
+      DeliverFrameCallback* callback) = 0;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_PORT_BROWSER_RENDER_WIDGET_HOST_VIEW_FRAME_SUBSCRIBER_H_