compositor-worker: Initialize CW machinery plumbing to compositor and fire CW rAF callbacks.

third_party/WebKit/Source/web/WebViewImpl.h

Index: third_party/WebKit/Source/web/WebViewImpl.h
diff --git a/third_party/WebKit/Source/web/WebViewImpl.h b/third_party/WebKit/Source/web/WebViewImpl.h
index 6c951efa8a18064d8102ae9893c6cd1ae9230519..786eb028b870471575fdb67166862f182118a411 100644
--- a/third_party/WebKit/Source/web/WebViewImpl.h
+++ b/third_party/WebKit/Source/web/WebViewImpl.h
@@ -87,6 +87,7 @@ class WebLayerTreeView;
 class WebLocalFrame;
 class WebLocalFrameImpl;
 class WebImage;
+class CompositorMutatorImpl;
 class WebPagePopupImpl;
 class WebPlugin;
 class WebRemoteFrame;
@@ -502,6 +503,7 @@ public:
     void forceNextWebGLContextCreationToFail() override;
     void forceNextDrawingBufferCreationToFail() override;
 
+    CompositorProxyClient* createCompositorProxyClient();
     IntSize mainFrameSize();
     WebDisplayMode displayMode() const { return m_displayMode; }
 
@@ -743,6 +745,11 @@ private:
 
     FloatSize m_elasticOverscroll;
 
+    // This is owned by the LayerTreeHostImpl, and should only be used on the
+    // compositor thread. The LayerTreeHostImpl is indirectly owned by this
+    // class so this pointer should be valid until this class is destructed.

[haraken, 2016/05/06 02:45:51]

Then can we remove the m_mutator by looking up the mutator via
LayerTreeHostImpl? It's not a good idea to introduce an unnecessary
CrossThreadPersistent because it might cause leaks.

[flackr, 2016/05/06 18:15:08]

We might technically be able to get it through WebLayerTreeView -> LayerTreeHost
-> Proxy-> ChannelMain -> LayerTreeHostImpl -> CompositorThreadOnly -> ProxyImpl
-> LayerTreeHostImpl, but not only is that a long path which needs to include
the thread hop, I'm somewhat concerned about race conditions on creating the
CompositorMutatorImpl. LayerTreeHostImpl can't create it because it's in cc/, so
because we create it in WebViewImpl and it eventually makes it over there, we
won't know if we get a nullptr response whether there is already a
CompositorMutatorImpl in flight waiting for the next commit to be sent over to
LayerTreeHostImpl.

Jeremy and I had an idea for how WebViewImpl could make a a callback, and pass
it to the LayerTreeHostImpl to run to create the CompositorMutatorImpl, however
Dana had concerns with the extra interfaces necessary for this kind of a
callback.

If I understand your concern, having m_mutator could keep the
CompositorMutatorImpl alive? It looks like resetting the pointer in
WebViewImpl::willCloseLayerTreeView might protect against this.

+    CrossThreadPersistent<CompositorMutatorImpl> m_mutator;
+
     Persistent<EventListener> m_popupMouseWheelEventListener;
 
     WebPageImportanceSignals m_pageImportanceSignals;