mus: Modify mojo command buffer to match current chrome gpu ipc.

components/mus/public/interfaces/command_buffer.mojom

Index: components/mus/public/interfaces/command_buffer.mojom
diff --git a/components/mus/public/interfaces/command_buffer.mojom b/components/mus/public/interfaces/command_buffer.mojom
index d48f9873c1273ac9ce626da6f588b1acd6da013d..90e52a6382d23dd15d2cd17d3afecad65b5a54f5 100644
--- a/components/mus/public/interfaces/command_buffer.mojom
+++ b/components/mus/public/interfaces/command_buffer.mojom
@@ -6,6 +6,8 @@ module mus.mojom;
 
 import "gpu/command_buffer/common/capabilities.mojom";
 import "gpu/command_buffer/common/command_buffer.mojom";
+import "gpu/command_buffer/common/mailbox.mojom";
+import "gpu/command_buffer/common/sync_token.mojom";
 import "ui/mojo/geometry/geometry.mojom";
 
 struct CommandBufferInitializeResult {
@@ -14,8 +16,16 @@ struct CommandBufferInitializeResult {
   gpu.mojom.Capabilities capabilities;
 };
 
-interface CommandBufferLostContextObserver {
-  DidLoseContext(int32 context_lost_reason);
+interface CommandBufferObserver {

[Fady Samuel, 2016/02/09 22:53:39]

Could we call this CommandBufferClient instead?

[Peng, 2016/02/10 18:56:55]

Done.

+  Destroyed(int32 context_lost_reason,
+            int32 error);
+  SignalAck(uint32 id);
+  // TODO(penghuang): support latency_info and use gfx::SwapResult for result.
+  SwapBuffersCompleted(/* array<ui.mojom.LatencyInfo> latency_info, */
+                       int32 result);
+  UpdateState(gpu.mojom.CommandBufferState state);
+  // TODO(penghuang): use base::TimeTicks & base::TimeDelta.
+  UpdateVSyncParameters(int64 timebase, int64 interval);
 };
 
 interface CommandBuffer {
@@ -23,7 +33,7 @@ interface CommandBuffer {
   // If the context is lost after creation the LostContext method on the
   // CommandBufferLostContextObserver's will be called then this pipe will be
   // closed.
-  Initialize(CommandBufferLostContextObserver lost_observer,
+  Initialize(CommandBufferObserver observer,
              handle<shared_buffer> shared_state,
              array<int32> attribs) => (CommandBufferInitializeResult? result);
   SetGetBuffer(int32 buffer);
@@ -32,7 +42,6 @@ interface CommandBuffer {
   RegisterTransferBuffer(
       int32 id, handle<shared_buffer> transfer_buffer, uint32 size);
   DestroyTransferBuffer(int32 id);
-
   CreateImage(int32 id,
               handle memory_handle,
               int32 type,
@@ -40,4 +49,13 @@ interface CommandBuffer {
               int32 format,
               int32 internal_format);
   DestroyImage(int32 id);
+  CreateStreamTexture(uint32 client_texture_id)

[Fady Samuel, 2016/02/09 22:45:16]

Yuzhu: These IPCs with callbacks need to be sync IPCs? How are we going to do
sync IPCs here? Would adding the [Sync] attribute give us sync? Is that work
ready yet?

[yzshen1, 2016/02/09 22:51:11]

I don't think I understand this part well enough to tell whether these messages
need to be sync or not.

Async calls can have callback, too.
The work is not ready yet. It will be ready in a few weeks, I think.
I am currently working on another issue (WTF-friendly generated code), but I
will give it higher priority if you or others need it soon.

When it is ready, yes, you add [Sync] and the call will become synchronous.

[Fady Samuel, 2016/02/09 22:55:59]

Actually, not lgtm Chatting with Yuzhu offline, we won't have [Sync] for a few
weeks. Could you please follow my porting to mojo doc's pattern for sync IPC?
Thanks!

+      => (int32 stream_id, bool succeeded);
+  ProduceFrontBuffer(gpu.mojom.Mailbox mailbox);
+  SignalQuery(uint32 query, uint32 signal_id);
+  SignalSyncToken(gpu.mojom.SyncToken sync_token, uint32 signal_id);
+  WaitForGetOffsetInRange(int32 start, int32 end)
+      => (gpu.mojom.CommandBufferState state);
+  WaitForTokenInRange(int32 start, int32 end)
+      => (gpu.mojom.CommandBufferState state);
 };