Initial checkin of the new Mozart compositor.

services/gfx/compositor/backend/output.h

Index: services/gfx/compositor/backend/output.h
diff --git a/services/gfx/compositor/backend/output.h b/services/gfx/compositor/backend/output.h
new file mode 100644
index 0000000000000000000000000000000000000000..e3df5d25d0731a84c9f282d858413a290bf213a5
--- /dev/null
+++ b/services/gfx/compositor/backend/output.h
@@ -0,0 +1,35 @@
+// 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_BACKEND_OUTPUT_H_
+#define SERVICES_GFX_COMPOSITOR_BACKEND_OUTPUT_H_
+
+#include <memory>
+
+#include "base/macros.h"
+
+namespace compositor {
+
+class RenderFrame;
+class Scheduler;
+
+// Renders snapshotted frames of the scene graph to a display output.

[viettrungluu, 2016/01/04 21:08:23]

Could you comment on any thread-safety requirements of implementations of
Output? (Partly to help me understand GpuOutput better....)

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

Done.

+class Output {
+ public:
+  Output() = default;

[viettrungluu, 2016/01/04 21:08:23]

nit: I think we'd usually just say "{}" instead of "= default;" for default
constructors (and also destructors). <shrug>

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

Yeah.  I'm experimenting with the style mostly.  Using "default" feels a little
nicer for abstract classes that only contain pure virtual methods.

+  virtual ~Output() = default;
+
+  // Gets the output's frame scheduler.
+  virtual Scheduler* scheduler() = 0;

[viettrungluu, 2016/01/04 21:08:23]

nit: lowercase_c_style() is usually reserved for inlined getters/setters/etc.
(which admittedly is a stupid rule), and typically wouldn't be used for
something virtual, I think. (So this would typically be called GetScheduler().)

(I don't feel very strongly about this, and don't know if anyone else does.)

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

Done.

+
+  // Submits a frame to be rendered to the display.
+  virtual void SubmitFrame(const std::shared_ptr<RenderFrame>& frame) = 0;

[viettrungluu, 2016/01/04 21:08:23]

I wonder if this should take an std::shared_ptr<RenderFrame>&& instead (the main
advantage being that this could avoid some refcount churn). <shrug>

Or maybe an std::shared_ptr<RenderFrame>. (This has the advantage of not being
annoying for the caller when they actually want to hold on to a reference, at
the cost of easier accidental churn.)

Not a big deal in any case.

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

I think the style guide says we should only use && for move constructors. 
Passing a const reference at least avoids potentially creating a temporary for
no reason as is common practice for many other reference counted objects.

+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(Output);
+};
+
+}  // namespace compositor
+
+#endif  // SERVICES_GFX_COMPOSITOR_BACKEND_OUTPUT_H_