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 7f1d23c77c98a2df04b62ade354ff12184ef1f4f..057bc0a5b3ef15ff95999c9f243d1df60a543e00 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;
@@ -505,6 +506,7 @@ public:
     void forceNextWebGLContextCreationToFail() override;
     void forceNextDrawingBufferCreationToFail() override;
 
+    CompositorProxyClient* createCompositorProxyClient(double referenceMonotonicTime);
     IntSize mainFrameSize();
     WebDisplayMode displayMode() const { return m_displayMode; }
 
@@ -744,6 +746,10 @@ private:
 
     FloatSize m_elasticOverscroll;
 
+    // This is owned by the LayerTreeHostImpl, and should only be used on the
+    // compositor thread.
+    CompositorMutatorImpl* m_mutator;

[jbroman, 2016/04/29 19:42:23]

A note about lifetime would be great here, too. Why is the CompositorMutatorImpl
guaranteed to outlive the WebViewImpl (such that this won't become a dangling
pointer)?

[flackr, 2016/05/03 22:24:55]

Not exactly true - LayerTreeHostImpl is indirectly owned by this so the pointer
becomes invalid during destruction but we shouldn't be using it at that point.
I've added a comment to that effect but let me know if you think it needs
further clarification. I could also set it to nullptr in the destructor so that
the pointer is unset before it is later destructed by the destruction of the
LayerTreeHostImpl.

+
     Persistent<EventListener> m_popupMouseWheelEventListener;
 
     WebPageImportanceSignals m_pageImportanceSignals;