Add CompositorFrameSinkClientBinding To Be Used By FrameGenerator

services/ui/ws/compositor_frame_sink_client_binding.h

+// Copyright 2017 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_UI_WS_COMPOSITOR_FRAME_SINK_CLIENT_BINDING_H_
+#define SERVICES_UI_WS_COMPOSITOR_FRAME_SINK_CLIENT_BINDING_H_
+
+#include "base/macros.h"
+#include "cc/ipc/frame_sink_manager.mojom.h"
+#include "cc/ipc/mojo_compositor_frame_sink.mojom.h"
+#include "cc/surfaces/local_surface_id_allocator.h"
+#include "mojo/public/cpp/bindings/binding.h"
+
+namespace ui {
+namespace ws {
+
+// CompositorFrameSinkClientBinding manages the binding between a FrameGenerator
+// and its MojoCompositorFrameSink. CompositorFrameSinkClientBinding exists so
+// that a mock implementation of MojoCompositorFrameSink can be injected for
+// tests. FrameGenerator owns its associated CompositorFrameSinkClientBinding.
+// TODO(staraz): DisplayClientCompositorFrameSink implements
+// CompositorFrameSinkClientBinding
+class CompositorFrameSinkClientBinding {

[Fady Samuel, 2017/05/17 20:33:04]

What if this implements cc::mojom::MojoCompositorFrameSink? That way, the
binding API never goes stale...

[Alex Z., 2017/05/17 20:52:01]

Would it be weird if there is a MojoCFS implementation on the client 
side? I'm fine with it otherwise.

[Alex Z., 2017/05/17 21:20:24]

A few more concerns:
ClientBinding starts to seem redundant once it implements MojoCFS: it
doesn't have anything in addition to MojoCFS methods.

The Default implementation handles LocalSurfaceId allocation 
(ClientBinding::SubmitCompositorFrame doesn't take in a 
LocalSurfaceId). DisplayPrivate::ResizeDisplay and SetLocalSurfaceId
need to be called when we allocate a new LocalSurfaceId. If we move
the LocalSurfaceId allocation back to FrameGenerator, either 
FrameGenerator needs to know about DisplayPrivate (which defeats the 
point of this CL) or we store a last_submitted_local_surface_id_ in
both FrameGenerator and ClientBinding. 

WDYT?

[Fady Samuel, 2017/05/18 11:55:27]

Not at all. The InterfacePtr probably also implements the
MojoCompositorFrameSInk interface.

[Fady Samuel, 2017/05/18 11:55:27]

Yea, we store the LocalSurfaceId in both places (client and service-side) in
Chrome too. I think that's fine. Don't expose DisplayPrivate to FrameGenerator
though.

+ public:
+  virtual ~CompositorFrameSinkClientBinding() = default;
+  virtual void SubmitCompositorFrame(cc::CompositorFrame frame) = 0;
+  virtual void SetNeedsBeginFrame(bool needs_begin_frame) = 0;
+};
+
+// Bindings implementation of CompositorFrameSinkClientBinding.
+class DefaultCompositorFrameSinkClientBinding
+    : public CompositorFrameSinkClientBinding {
+ public:
+  DefaultCompositorFrameSinkClientBinding(
+      cc::mojom::MojoCompositorFrameSinkClient* sink_client,
+      cc::mojom::MojoCompositorFrameSinkClientRequest sink_client_request,
+      cc::mojom::MojoCompositorFrameSinkAssociatedPtr compositor_frame_sink,
+      cc::mojom::DisplayPrivateAssociatedPtr display_private);
+  ~DefaultCompositorFrameSinkClientBinding() override;
+
+  // CompositorFrameSinkClientBinding implementation:
+  void SubmitCompositorFrame(cc::CompositorFrame frame) override;
+  void SetNeedsBeginFrame(bool needs_begin_frame) override;
+
+ private:
+  mojo::Binding<cc::mojom::MojoCompositorFrameSinkClient> binding_;
+  cc::mojom::DisplayPrivateAssociatedPtr display_private_;
+  cc::mojom::MojoCompositorFrameSinkAssociatedPtr compositor_frame_sink_;
+  cc::LocalSurfaceId local_surface_id_;
+  cc::LocalSurfaceIdAllocator id_allocator_;
+  gfx::Size last_submitted_frame_size_;
+
+  DISALLOW_COPY_AND_ASSIGN(DefaultCompositorFrameSinkClientBinding);
+};
+}
+}
+
+#endif  // SERVICES_UI_WS_COMPOSITOR_FRAME_SINK_CLIENT_BINDING_H_