Initial checkin of the new Mozart compositor.

services/gfx/compositor/graph/resource_def.h

Index: services/gfx/compositor/graph/resource_def.h
diff --git a/services/gfx/compositor/graph/resource_def.h b/services/gfx/compositor/graph/resource_def.h
new file mode 100644
index 0000000000000000000000000000000000000000..4f38b05b2e2e4f377ded9b88adb8cddf9bc5c6a9
--- /dev/null
+++ b/services/gfx/compositor/graph/resource_def.h
@@ -0,0 +1,71 @@
+// 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 SERVICES_GFX_COMPOSITOR_GRAPH_RESOURCE_DEF_H_
+#define SERVICES_GFX_COMPOSITOR_GRAPH_RESOURCE_DEF_H_
+
+#include <memory>
+
+#include "base/macros.h"
+#include "mojo/services/gfx/composition/interfaces/resources.mojom.h"
+#include "services/gfx/compositor/render/render_image.h"
+
+namespace compositor {
+
+class SceneDef;
+
+// Abstract scene graph resource definition.
+class ResourceDef {
+ public:
+  enum class Type { kScene, kImage };
+
+  ResourceDef() = default;
+  virtual ~ResourceDef() = default;
+
+  // Gets the resource type.
+  virtual Type type() const = 0;
+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(ResourceDef);
+};
+
+// Reference to another scene expressed as a resource definition.
+// The pointer may be null if the referenced scene has become unavailable.
+class SceneResourceDef : public ResourceDef {
+ public:
+  explicit SceneResourceDef(SceneDef* referenced_scene);
+  ~SceneResourceDef() override;
+
+  Type type() const override;
+
+  // The referenced scene, may be null if unavailable.
+  SceneDef* referenced_scene() { return referenced_scene_; }
+  void clear_referenced_scene() { referenced_scene_ = nullptr; }
+
+ private:
+  SceneDef* referenced_scene_;

[abarth, 2016/01/10 22:55:36]

What is the lifetime relationship between this object and referenced_scene_ ? 
The raw pointer makes this very unclear.  Based on the clear_referenced_scene()
function above, it looks like this might be a weak pointer...  Should we use
some sort of pointer type to make the lifetime relationship explicit?

[jeffbrown, 2016/01/16 03:28:32]

I'm using bare pointers because I can guarantee that they aren't left dangling
by mutations, I don't want reference counting, and I need more control than a
weak pointer offers.

I agree it's a bit more opaque this way so I may revisit it later.  I'll add a
comment here.

See SceneDef::UnlinkReferencedScene.

+
+  DISALLOW_COPY_AND_ASSIGN(SceneResourceDef);
+};
+
+// Reference to an image expressed as a resource definition.
+class ImageResourceDef : public ResourceDef {
+ public:
+  explicit ImageResourceDef(const std::shared_ptr<RenderImage>& image);
+  ~ImageResourceDef() override;
+
+  Type type() const override;
+
+  // The referenced image, may be null if unavailable.
+  const std::shared_ptr<RenderImage>& image() { return image_; }
+
+ private:
+  std::shared_ptr<RenderImage> image_;

[abarth, 2016/01/10 22:55:36]

I think I raised this before, but shared_ptr is not particularly efficient.  We
probably want to use scoped_refptr or some other intrusive ref pointer that
doesn't have a built-in weak pointer confusing things.

It's ok to use shared_ptr in examples to avoid dragging in extra dependencies,
but in production code, I think we should be using a ref pointer that's more
optimized for our use cases.

[jeffbrown, 2016/01/16 03:28:32]

I am actually using weak_ptr semantics here.  It's actually a good fit for this
case.

+
+  DISALLOW_COPY_AND_ASSIGN(ImageResourceDef);
+};
+
+}  // namespace compositor
+
+#endif  // SERVICES_GFX_COMPOSITOR_GRAPH_RESOURCE_DEF_H_