Introduce DisplayCompositor Mojo API for Mus

components/mus/public/interfaces/display_compositor.mojom

+// 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.
+
+module mus.mojom;
+
+import "components/mus/public/interfaces/compositor_frame.mojom";
+
+// Indicates whether the submitted CompositorFrame has been drawn to the display
+// or has been skipped (e.g. another frame may have been submitted before
+// vblank).
+enum CompositorFrameDrawStatus {
+  DRAW_SKIPPED,
+  DRAWN
+};
+
+// A CompositorFrameSinkFactory represents a single Display client.
+// The client (a process) can use this interface to create
+// CompositorFrameSinks.
+// TODO(fsamuel): This needs a better name.
+interface CompositorFrameSinkFactory {
+  // Requests a CompositorFrameSink interface from the display compositor.
+  // A CompositorFrameSink has an associated ID consisting of three components:
+  // 1. Namespace picked by the service associated with this
+  //    CompositorFrameSinkFactory
+  // 2. |local_id| which is a monotonically increasing ID allocated by the
+  //    client.
+  // 3. |nonce| is a cryptographically secure random number making this Sink

[rjkroege, 2016/05/25 23:01:55]

I am not convinced that nonce generation should be a client responsibility. It
seems that this puts the onus on clients to do the "right" thing instead of code
in mus doing it once for everybody. Mojo apps cannot necessarily be relied to do
the right thing.

[Fady Samuel, 2016/05/26 00:30:07]

Doing nonce more securely on the service is harder I think. If we do it naively
then we only get one nonce per client as opposed to a nonce per sink meaning if
a nonce is somehow guessed then all sinks within a client would be guessable.

If we create a nonce per sink in the browser, then we would need to:

1. Pass the nonce back to the client so it can embed things it owns. Doing this
asynchronously is hard.
2. Use a sync IPC, which is bad for performance.

+  //    unguessable by other clients.
+  CreateCompositorFrameSink(uint32 local_id,
+                            uint64 nonce,
+                            CompositorFrameSink& sink,
+                            CompositorFrameSinkClient client);
+};
+
+// A CompositorFrameSink is an interface for receiving CompositorFrame structs.
+// A CompositorFrame contains the complete output meant for display. Each time a

[rjkroege, 2016/05/25 23:01:55]

nit: This isn't quite true. But doesn't matter.

[Fady Samuel, 2016/05/26 00:30:07]

Acknowledged.

+// client has a graphical update, and receives an OnBeginFrame, it is
+// responsible for creating a CompositorFrame to update its portion of the
+// screen.
+interface CompositorFrameSink {
+  // After the submitted frame is either drawn for the first time by the display
+  // compositor or discarded, the callback will be called with the status of the
+  // submitted frame. Clients should use this acknowledgement to ratelimit frame
+  // submissions.
+  SubmitCompositorFrame(CompositorFrame frame) =>
+      (CompositorFrameDrawStatus status);

[rjkroege, 2016/05/25 23:01:55]

see previous comment set: I think we should support identifying the CF in the
callback. You address this a TODO.

[Fady Samuel, 2016/05/26 00:30:07]

Done.

+
+  // 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 CompositorFrameSinkClient {
+  ReturnResources(array<ReturnedResource> resources);
+};
+
+// This is a public interface implemented by Display clients.
+// Each client implements a single instance of the DisplayClient interface.
+interface DisplayClient {
+  // The Mus Window Server is a root client, and so it will receive this
+  // callback. There can only be one root CompositorFrameSink per Display and so
+  // it does not get a CompositorFrameSinkFactory.
+  OnRootClientCreated(CompositorFrameSink sink,

[rjkroege, 2016/05/25 23:01:55]

you are still forcing DisplayClient implementations other than the Window server
to implement this interface. I am opposed.

[Fady Samuel, 2016/05/26 00:30:07]

Done. We now have a DisplayClient and DisplayHost. DisplayCompositor has gotten
a bit more complicated but oh well. We can clean things up in a client lib.

+                      CompositorFrameSinkClient& client);
+
+  // Non-root clients will receive this callback. Clients can create
+  // CompositorFrameSinks via the provided |factory|.
+  OnClientCreated(uint32 client_id, CompositorFrameSinkFactory factory);
+
+  // TODO(fsamuel): OnBeginFrame needs to take a BeginFrameArgs instance per
+  // cc/output/begin_frame_args.h.
+  OnBeginFrame();
+};