Use element id's for animations

cc/animation/element_id.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 CC_ANIMATION_ELEMENT_ID_H_
+#define CC_ANIMATION_ELEMENT_ID_H_
+
+#include <cstdint>
+#include <functional>
+#include <iosfwd>
+#include <memory>
+#include <stddef.h>
+
+#include "cc/base/cc_export.h"
+
+namespace base {
+class Value;
+namespace trace_event {
+class TracedValue;
+}  // namespace trace_event
+}  // namespace base
+
+namespace cc {
+
+namespace proto {
+class ElementId;
+}  // namespace proto
+
+// ------------------------------*IMPORTANT*---------------------------------
+// ElementId has a corresponding proto defined in cc/proto/element_id.proto.
+// When making any changes here, but sure to update the proto.
+
+struct CC_EXPORT ElementId {

[Ian Vollick, 2016/06/01 18:08:26]

Why a struct?
 1. Catch bugs. I started with a type alias, but I hit a large number of bugs
(eg, LayerById would accept an ElementId).
 2. Flexibility. The innards of this struct are the most interesting part of
this patch, and by encapsulating those details, it will be easier to change them
in future if we need to.

+  explicit ElementId(uint64_t value) : value(value) {}
+  ElementId() : value(0ul) {}
+
+  inline bool operator==(const ElementId& o) const { return o.value == value; }
+  inline bool operator!=(const ElementId& o) const { return o.value != value; }
+  inline bool operator<(const ElementId& o) const { return value < o.value; }
+  inline explicit operator bool() const { return !!value; }
+
+  void AddToTracedValue(base::trace_event::TracedValue* res) const;
+  std::unique_ptr<base::Value> AsValue() const;
+
+  void ToProtobuf(proto::ElementId* proto) const;
+  void FromProtobuf(const proto::ElementId& proto);
+
+  uint64_t value;

[Ian Vollick, 2016/06/01 18:08:25]

I went with a uint64_t here because I wanted cc to be wholly ignorant of the
meaning of this value. Although it is possible to hide the innards from cc code,
I wanted to avoid the concept from leaking into code. That said, there are other
options here.

 1. We could store two numbers here, an element id and a sub element id.
 2. We could teach DOMNodeIds to vend extra ids for non-DOM stuff. I don't
particularly like this approach because it doesn't allow us to link auxiliary
ids with an element. Specifically, it would preclude the removal of
ElementLayers, which I think is a nice feature of this patch.

[ajuma, 2016/06/01 23:53:42]

(1) has the nice feature that you avoid bitwise OR-ing when calling setElementId
in blink, but maybe one way to accomplish the same goal is to add a helper
somewhere in blink (in CompositorElementId.h?) that takes the main id and
sub-ids and turns them into an actual id (and then the OR-ing is an
implementation detail of that helper rather than exposed everywhere)?

[Ian Vollick, 2016/06/02 19:03:11]

I've tried out the helper function in the latest patch set.

+};
+
+ElementId CC_EXPORT LayerIdToElementIdForTesting(int layer_id);
+
+struct ElementIdHash {
+  size_t operator()(ElementId key) const {
+    return std::hash<uint64_t>()(key.value);
+  }
+};
+
+// Stream operator so ElementId can be used in assertion statements.
+CC_EXPORT std::ostream& operator<<(std::ostream& out, const ElementId& id);
+
+}  // namespace cc
+
+#endif  // CC_ANIMATION_ELEMENT_ID_H_