Move SharedBitmapManager implementation out of content/

cc/ipc/shared_bitmap_manager.mojom

+// 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.
+
+module cc.mojom;
+
+import "gpu/ipc/common/mailbox.mojom";
+
+// This interface is used for allocating shared bitmap memory from display

[danakj, 2017/04/06 15:00:51]

I think this can be reworded a bit. The API doesn't actually allocate anything.
Instead, "This interface is used when allocating shared bitmap memory to be
shared with a display compositor."

[xlai (Olivia), 2017/04/06 20:42:26]

Done here and elsewhere.

+// compositor. For mus+ash, this service will live in where the display

[danakj, 2017/04/06 15:00:51]

And then I would drop the "For mus+ash..." sentence.

+// compositor lives. 
+// This interface needs to be associated with the RenderMessageFilter interface
+// to prevent running into message ordering issues (CC trying to access a
+// shared bitmap before the registration message below made it to the display
+// compositor).
+interface SharedBitmapManager {
+  // Informs the display compositor that the child allocated a shared bitmap.
+  AllocatedSharedBitmap(handle<shared_buffer> buffer, gpu.mojom.Mailbox id);

[Tom Sepez, 2017/04/06 16:44:04]

nit: maybe call this DidAllocateSharedBitmap().  Or not.

+
+  // Informs the display compositor that the child deleted a shared bitmap.
+  DeletedSharedBitmap(gpu.mojom.Mailbox id);

[Tom Sepez, 2017/04/06 16:44:04]

nit: maybe call this WillDeleteSharedBitmap().  This happens just prior to
deletion, right?

[xlai (Olivia), 2017/04/06 20:42:26]

Done here and elsewhere. I think this should be DidDeleteSharedBitmap because it
occurs when the shared bitmap deletion is confirmed (in destructor); also it is
consistent with DidAllocateSharedBitmap.

+};