Move part of display_compositor's interface to cc/ipc

cc/ipc/mojo_compositor_frame_sink.mojom

Index: cc/ipc/mojo_compositor_frame_sink.mojom
diff --git a/cc/ipc/mojo_compositor_frame_sink.mojom b/cc/ipc/mojo_compositor_frame_sink.mojom
new file mode 100644
index 0000000000000000000000000000000000000000..4bb9db7a8e5b2cdb7a9b3744ae3dd56158df9c07
--- /dev/null
+++ b/cc/ipc/mojo_compositor_frame_sink.mojom
@@ -0,0 +1,29 @@
+// 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.
+
+import "cc/ipc/compositor_frame.mojom";
+import "cc/ipc/returned_resource.mojom";
+

[Fady Samuel, 2016/09/16 14:08:02]

Please place in module cc.mojom;

[xidachen, 2016/09/16 14:32:00]

Done.

+// A MojoCompositorFrameSink is an interface for receiving CompositorFrame
+// structs. A CompositorFrame contains the complete output meant for display.
+// Each time a client has a graphical update, and receives an OnBeginFrame, it
+// is responsible for creating a CompositorFrame to update its portion of the
+// screen.
+interface MojoCompositorFrameSink {

[Fady Samuel, 2016/09/16 14:08:02]

Please rename to CompositorFrameSink. Mojo is redundant.

[xidachen, 2016/09/16 14:32:00]

This prefix is suggested by Dana. Her concern is that without this prefix, when
people talk about CompositorFrameSink, it is confusing because cc already have a
CompositorFrameSink class.

[Fady Samuel, 2016/09/16 14:35:50]

Dana, Xida, we place all cc mojo interfaces in a cc::mojom namespace for this
purpose. I think the mojom namespace captures the fact that this is mojo and so
there shouldn't be any confusion, WDYT?

[danakj, 2016/09/16 17:56:37]

I asked for it. When we talk about classes we talk about them by name, and
having two classes with the same name under cc/ seems like its going to be
confusing. We can rename it when there aren't two with the same name?

[Fady Samuel, 2016/09/16 18:00:36]

Sure. sgtm

+  // After the submitted frame is either drawn for the first time by the display
+  // compositor or discarded, the callback will be called. Clients should use
+  // this acknowledgement to ratelimit frame submissions.
+  // TODO(fsamuel): We should support identifying the CF in the callback.
+  SubmitCompositorFrame(cc.mojom.CompositorFrame frame) => ();

[Fady Samuel, 2016/09/16 14:08:03]

I  don't think we need the callback? danakj@ could answer better I think. Frame
ratelimiting is now determined by unified beginframe.

[xidachen, 2016/09/16 14:32:00]

I will defer that to danakj@. Thanks.

[danakj, 2016/09/16 17:56:37]

We still need a swap ack for now, scheduler would DCHECK if it did not receive a
swap ack.

[Fady Samuel, 2016/09/16 18:00:36]

OK

+
+  // Lets the display compositor know that the client wishes to receive the next
+  // BeginFrame event.
+  SetNeedsBeginFrame(bool needs_begin_frame);
+
+  // TODO(fsamuel): ReadbackBitmap API would be useful here.
+};
+
+interface MojoCompositorFrameSinkClient {

[Fady Samuel, 2016/09/16 14:08:02]

Drop mojo please. It's redundant.

+  ReturnResources(array<cc.mojom.ReturnedResource> resources);
+};