compositor-worker: Introduce WebCompositorMutableState

third_party/WebKit/public/platform/WebCompositorMutableStateProvider.h

Index: third_party/WebKit/public/platform/WebCompositorMutableStateProvider.h
diff --git a/third_party/WebKit/public/platform/WebCompositorMutableStateProvider.h b/third_party/WebKit/public/platform/WebCompositorMutableStateProvider.h
new file mode 100644
index 0000000000000000000000000000000000000000..f4b5288ed2b334749ec3e6d5a73eca64683a201d
--- /dev/null
+++ b/third_party/WebKit/public/platform/WebCompositorMutableStateProvider.h
@@ -0,0 +1,26 @@
+// Copyright 2015 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 WebCompositorMutableStateProvider_h
+#define WebCompositorMutableStateProvider_h
+
+#include <cstdint>
+
+namespace blink {
+
+class WebCompositorMutableState;
+
+// This class is a window onto compositor-owned state. It vends out wrappers
+// around per-element bits of this state.
+class WebCompositorMutableStateProvider {

[esprehn, 2015/12/16 04:01:59]

This is dead code right now, where is it going to get used?

[Ian Vollick, 2015/12/23 17:34:40]

At a high level, when we execute the compositor-worker callbacks we send out to
blink a fresh wrapper around the compositor state. The CompositorProxies are
connected to the appropriate state before the callbacks are executed
(https://codereview.chromium.org/1547893003/diff/1/third_party/WebKit/Source/w...).

+public:
+    virtual ~WebCompositorMutableStateProvider() { }
+
+    // The caller is expected to take ownership.
+    virtual WebCompositorMutableState* getMutableStateFor(uint64_t elementId) = 0;

[esprehn, 2015/12/16 04:01:58]

return a WebPassOwnPtr, how does the caller know when to call this?

[Ian Vollick, 2015/12/23 17:34:40]

Done.

In the current mega-patch (linked above), we grab a mutable state wrapper for
the proxies before executing the compositor worker callbacks. We have a lot of
flexibility about how we connect the proxies to the state, though. Some other
alternatives I'd considered were
 * not wrapping the per-element mutable state.
   * this has a big downside: if we don't cache the per-element state, every
property read and write is a hash map lookup.
 * lazily creating the per-element wrappers for the compositor proxies
   * This may actually be a good way to go, but it's orthogonal to this patch,
so I'd prefer to leave that discussion to the subsequent patch that connects the
CompositorProxies to the compositor's mutable state.

+};
+
+} // namespace blink
+
+#endif // WebCompositorMutableStateProvider_h