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

third_party/WebKit/Source/web/CompositorMutatorImpl.h

+// Copyright 2016 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 CompositorMutatorImpl_h
+#define CompositorMutatorImpl_h
+
+#include "core/animation/CustomCompositorAnimationManager.h"
+#include "platform/graphics/CompositorMutator.h"
+#include "platform/heap/Handle.h"
+#include "platform/heap/HeapAllocator.h"
+#include "wtf/Noncopyable.h"
+#include "wtf/OwnPtr.h"
+#include "wtf/PassOwnPtr.h"
+
+namespace blink {
+
+class CompositorProxy;
+class CompositorProxyClientImpl;
+class CompositorWorkerGlobalScope;
+class CompositorMutatorClient;
+class WaitableEvent;
+
+// Fans out requests from the compositor to all of the registered ProxyClients which
+// can then mutate layers through their CompositorProxy interfaces. Requests for
+// animation frames are received from ProxyClients and sent to the compositor to
+// generate a new compositor frame.
+//
+// Should be accessed only on the compositor thread.
+class CompositorMutatorImpl final : public GarbageCollectedFinalized<CompositorMutatorImpl>, public CompositorMutator {

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

Why do you need to make CompositorMutator a GarbageCollectedMixin? Can we just
make CompositorMutator GarbageCollectedFinalized and remove
GarbageCollectedFinalized from the subclasses?

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

Jeremy pointed out that the interface doesn't really know whether the
implementation will need finalization. Is it preferred not to have mixins?

See his comment here:
https://codereview.chromium.org/1895873006/diff/80001/third_party/WebKit/Sour...

+    WTF_MAKE_NONCOPYABLE(CompositorMutatorImpl);
+    USING_GARBAGE_COLLECTED_MIXIN(CompositorMutatorImpl);
+public:
+    static CompositorMutatorImpl* create();
+
+    DEFINE_INLINE_TRACE()
+    {
+        CompositorMutator::trace(visitor);
+        visitor->trace(m_proxyClients);
+    }
+
+    // CompositorMutator implementation.
+    bool mutate(double monotonicTimeNow) override;
+
+    void registerProxyClient(CompositorProxyClientImpl*);
+
+    void setNeedsMutate();
+
+    void setClient(CompositorMutatorClient* client) { m_client = client; }
+    CustomCompositorAnimationManager* animationManager() { return m_animationManager.get(); }
+
+private:
+    CompositorMutatorImpl();
+
+    using ProxyClients = HeapHashSet<WeakMember<CompositorProxyClientImpl>>;
+    ProxyClients m_proxyClients;

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

I just want to confirm why you use WeakMembers, but can CompositorMutatorImpl
outlive the CompositorProxyClientImpl?

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

Yes. the LayerTreeHostImpl has one CompositorMutatorImpl but
CompositorProxyClientImpl's come and go with the creation and destruction of
compositor workers.

+
+    OwnPtr<CustomCompositorAnimationManager> m_animationManager;
+    CompositorMutatorClient* m_client;
+};
+
+} // namespace blink
+
+#endif // CompositorMutatorImpl_h