Pull parts of TopLevelDisplayClient into DisplayCompositor

components/mus/surfaces/display_compositor.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 COMPONENTS_MUS_SURFACES_DISPLAY_COMPOSITOR_H_
+#define COMPONENTS_MUS_SURFACES_DISPLAY_COMPOSITOR_H_
+
+#include "cc/surfaces/surface_factory.h"
+#include "cc/surfaces/surface_factory_client.h"
+#include "cc/surfaces/surface_id_allocator.h"
+#include "components/mus/gles2/gpu_state.h"
+#include "components/mus/surfaces/surfaces_state.h"
+#include "ui/gfx/native_widget_types.h"
+
+namespace mus {
+
+class TopLevelDisplayClient;
+
+// TODO(fsamuel): This should become a mojo interface for the mus-gpu split.

[rjkroege, 2016/05/12 23:03:44]

in the sequencing of this work, when do we mojo-i-fy it?

[Fady Samuel, 2016/05/12 23:13:45]

Once mus/ws no longer directly refers to cc, then as a last step I'll make it a
mojo interface and use that instead.

+// TODO(fsamuel): This should not be a SurfaceFactoryClient.
+// The DisplayCompositor receives CompositorFrames from all sources,

[rjkroege, 2016/05/12 23:03:44]

this implies that DisplayCompositor is responsible for kicking off the
composition on vblank. Yes? So SubmitCompositorFrame is async.

[Fady Samuel, 2016/05/12 23:13:45]

Yes, SubmitCompositorFrame is async.

+// creates a top-level CompositorFrame once per tick, and generates graphical
+// output.
+class DisplayCompositor : public cc::SurfaceFactoryClient {

[rjkroege, 2016/05/12 23:03:44]

how will these have their ownership in musgpu tracked?

And... how does a musws reconnect to a DisplayCompositor after the musgpu has
experienced a sad.

[Fady Samuel, 2016/05/12 23:13:45]

mus-ws connects to mojo:musgpu, requests a DisplayCompositorFactory interface,
and from that, a DisplayCompositor.

+ public:
+  DisplayCompositor(scoped_refptr<base::SingleThreadTaskRunner> task_runner,
+                    gfx::AcceleratedWidget widget,
+                    const scoped_refptr<GpuState>& gpu_state,
+                    const scoped_refptr<SurfacesState>& surfaces_state);
+  ~DisplayCompositor() override;
+
+  void SubmitCompositorFrame(std::unique_ptr<cc::CompositorFrame> frame,

[rjkroege, 2016/05/12 23:03:44]

Please indicate when the callback gets invoked.

[Fady Samuel, 2016/05/12 23:13:45]

Done.

+                             const base::Closure& callback);
+
+  // TODO(fsamuel): This is used for surface hittesting and should not be

[rjkroege, 2016/05/12 23:03:44]

per our previous discussion, musws needs to maintain a window <-> surface
mapping. How does the musws get knowledge of the surfaces sufficient for using
the hit testing API?

[Fady Samuel, 2016/05/12 23:13:45]

See here: https://bugs.chromium.org/p/chromium/issues/detail?id=610937

The DisplayCompositor embedder specifies IDs for "CompositorFrameSinks".

+  // exposed outside of DisplayCompositor.
+  const cc::SurfaceId& surface_id() const { return surface_id_; }
+
+  void RequestCopyOfOutput(

[rjkroege, 2016/05/12 23:03:44]

what is this for?

[Fady Samuel, 2016/05/12 23:13:45]

Readback for screenshots.

+      std::unique_ptr<cc::CopyOutputRequest> output_request);
+
+  // TODO(fsamuel): Invent an async way to create a SurfaceNamespace
+  // A SurfaceNamespace can create CompositorFrameSinks where the client can
+  // make up the ID.
+
+ private:
+  // SurfaceFactoryClient implementation.
+  void ReturnResources(const cc::ReturnedResourceArray& resources) override;
+  void SetBeginFrameSource(cc::BeginFrameSource* begin_frame_source) override;
+
+  scoped_refptr<base::SingleThreadTaskRunner> task_runner_;
+  scoped_refptr<SurfacesState> surfaces_state_;
+  cc::SurfaceFactory factory_;
+  cc::SurfaceIdAllocator allocator_;
+  cc::SurfaceId surface_id_;
+
+  gfx::Size display_size_;
+  std::unique_ptr<TopLevelDisplayClient> display_client_;
+  DISALLOW_COPY_AND_ASSIGN(DisplayCompositor);
+};
+
+}  // namespace mus
+
+#endif  // COMPONENTS_MUS_SURFACES_DISPLAY_COMPOSITOR_H_