Convert offscreen canvas to use FrameSinkManagerHost.

content/browser/renderer_host/offscreen_canvas_surface_impl.cc

Index: content/browser/renderer_host/offscreen_canvas_surface_impl.cc
diff --git a/content/browser/renderer_host/offscreen_canvas_surface_impl.cc b/content/browser/renderer_host/offscreen_canvas_surface_impl.cc
index 3795b60ed0e282e2e29af90444648679990a5123..6fd12ccdd388c9117bc53f8679b95830fa0c9d99 100644
--- a/content/browser/renderer_host/offscreen_canvas_surface_impl.cc
+++ b/content/browser/renderer_host/offscreen_canvas_surface_impl.cc
@@ -28,10 +28,12 @@ OffscreenCanvasSurfaceImpl::OffscreenCanvasSurfaceImpl(
 }
 
 OffscreenCanvasSurfaceImpl::~OffscreenCanvasSurfaceImpl() {
-  if (frame_sink_id_.is_valid()) {
-    OffscreenCanvasCompositorFrameSinkManager::GetInstance()
-        ->UnregisterOffscreenCanvasSurfaceInstance(frame_sink_id_);
+  if (has_registered_frame_sink_hierarchy_) {
+    content::GetDisplayCompositor()->UnregisterFrameSinkHierarchy(

[xlai (Olivia), 2017/04/03 15:42:59]

Previously this is done in destroy of OffscreenCanvasCompositorFrameSink.
What happened when CompositorFrameSink is torn down whilst the
OffscreenCanvasSurface is still alive (worker thread dead but main thread
alive)? Then you'll have a (parent_frame_sink_id, child_frame_sink_id) pair in
the frame sink hierarchy of the display compositor such that the parent one is
alive but the child one will point to no compositor frame sink. Will that cause
a problem?

[kylechar, 2017/04/03 16:00:19]

The GpuCompositorFrameSink in DisplayCompositor is only destroyed when both
interfaces (MojoCompositorFrameSink and MojoCompositorFrameSinkPrivate) are
closed. So there will be a GpuCompositorFrameSink until this gets torn down.

I think the only constraints this puts on things are:
1. Renderer closes the OffscreenCanvasSurface connection only after it has
stopped submitting CFs that embed the offscreen canvas SurfaceId. This is
because the heirarchy unregistered here.
2. Renderer doesn't close MojoCompositorFrameSink connection (which I guess
means destroying OffscreenCanvasFrameDispatcherImpl) and then create a new
MojoCompositorFrameSink connection again using the same OffscreenCanvasSurface.

The order in which MojoCompositorFrameSink and OffscreenCanvasSurface
connections are closed shouldn't matter, although I'd assume they would
generally be closed around the same time? It's also possible to have started and
created an OffscreenCanvasSurface connection but never create the
MojoCompositorFrameSink connection associated with it.

+        parent_frame_sink_id_, frame_sink_id_);
   }
+  OffscreenCanvasCompositorFrameSinkManager::GetInstance()
+      ->UnregisterOffscreenCanvasSurfaceInstance(frame_sink_id_);
 }
 
 // static
@@ -48,6 +50,20 @@ void OffscreenCanvasSurfaceImpl::Create(
       mojo::MakeStrongBinding(std::move(impl), std::move(request));
 }
 
+void OffscreenCanvasSurfaceImpl::CreateCompositorFrameSink(
+    cc::mojom::MojoCompositorFrameSinkClientPtr client,
+    cc::mojom::MojoCompositorFrameSinkRequest request) {
+  DCHECK(!compositor_frame_sink_private_.is_bound());
+
+  content::GetDisplayCompositor()->CreateCompositorFrameSink(
+      frame_sink_id_, std::move(request),
+      mojo::MakeRequest(&compositor_frame_sink_private_), std::move(client));
+
+  content::GetDisplayCompositor()->RegisterFrameSinkHierarchy(
+      parent_frame_sink_id_, frame_sink_id_);
+  has_registered_frame_sink_hierarchy_ = true;
+}
+
 void OffscreenCanvasSurfaceImpl::OnSurfaceCreated(
     const cc::SurfaceInfo& surface_info) {
   DCHECK_EQ(surface_info.id().frame_sink_id(), frame_sink_id_);