Update Surface ID Terminology

cc/ipc/surface_id.mojom

 // Copyright 2014 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 cc.mojom;
 
-// A surface ID is composed of three parts: a namespace, a local ID, and a
-// nonce. The local part and nonce are allocated by the client using any scheme
-// that avoids duplicates and makes IDs unguessable respectively. The namespace
-// is allocated by the service and will be different for each client.
+// A surface id is composed of four parts: a gpu id, a client id, a local id,
+// and a nonce. The local part and nonce are allocated by the client using any
+// scheme that avoids duplicates and makes ids unguessable respectively. The gpu
+// id is allocated by the service and uniquely identifies the generation of the
+// gpu service. The client id is allocated by the service and will be different
+// for each client.
 //
-// The special id_namespace value 0 is equivalent to the namespace of the
-// client. This can be used to create, destroy and submit frames to
-// surfaces before learning the namespace and to reference other surfaces
-// owned by the same client. The actual id namespace must be used to pass
-// surface ids to other clients for them to reference.
+// The special gpu_id value 0 indicates software compositing. The special
+// client_id value 0 is equivalent to the client id of the current client. This
+// can be used to create, destroy and submit frames to surfaces before learning
+// the namespace and to reference other surfaces owned by the same client. The
+// actual client id must be used to pass surface ids to other clients for them
+// to reference.
 struct SurfaceId {
-  // A service allocated ID identifying a client.
-  uint32 id_namespace;
+  // A service allocated id identifying the generation of the gpu service.
+  // TODO(fsamuel): We don't need this if the display compositor always lives
+  // in the same process as the gpu service.

[piman, 2016/07/12 20:57:19]

TBH, I'm not sure that's true... This is to prevent races on the client side. It
could very well be that the display_compositor process sends an ack/returns
resources, then crashes. Meanwhile, the client detects the crash, recreates an
output surface, then receives the ack/resource returns. It needs a way to know
that the ack isn't relevant any more.

Or maybe you're saying that there's an out-of-band way to ensure that in the mus
world, similar to the output_surface_id today... if that's the case, is it worth
doing this (somewhat large) patch, just to revert it later?

[Fady Samuel, 2016/07/12 22:45:34]

Well, I think I've confused myself. Really output_surface_id looks like it's
used to establish a "connection". This isn't necessary once we switch to mojo
because each OutputSurface has a different messagepipe and a message from an old
GPU service cannot arrive to a new OutputSurface.

+  uint32 gpu_id;
+
+  // A service allocated id identifying a client.
+  uint32 client_id;
 
   // An identifier allocated by the client uniquely identifying a surface within
   // a client process.
   uint32 local_id;
 
   // A cryptographically secure random int chosen to make the SurfaceId
   // unguessable by other clients.
   uint64 nonce;
 };