Plumb GpuMemoryBuffer allocation to GPU process.

content/browser/gpu/browser_gpu_channel_host_factory.h

Index: content/browser/gpu/browser_gpu_channel_host_factory.h
diff --git a/content/browser/gpu/browser_gpu_channel_host_factory.h b/content/browser/gpu/browser_gpu_channel_host_factory.h
index c2637f033cc3ca00ce518c353f8c9e901037f68e..5d1e129669a5e142bd9cfaacce3d0574816ce0a8 100644
--- a/content/browser/gpu/browser_gpu_channel_host_factory.h
+++ b/content/browser/gpu/browser_gpu_channel_host_factory.h
@@ -41,6 +41,9 @@ class CONTENT_EXPORT BrowserGpuChannelHostFactory
       size_t height,
       unsigned internalformat,
       unsigned usage) OVERRIDE;
+  virtual void AllocateGpuMemoryBufferAsync(

[reveman, 2014/05/27 22:46:01]

I'd like to have this replace Create/DeleteImage.

I think that naming this Create/DestroyGpuMemoryBuffer will represent what it
does really well. See my comment below for more details.

[alexst (slow to review), 2014/05/28 14:18:57]

I was planning to add the new way first and then remove the old code as a
followup to not break existing functionality since I'm thinking it may take a
couple of CL to get everything done.

That said, if you are okay with CreateImage temporarily not work, I'll go down
that way.

[reveman, 2014/05/28 16:42:26]

Removing Create/DeleteImage in follow up patches is fine and sounds like a good
plan. We don't have to worry much about temporarily breaking it but I think we
should avoid doing that intentionally. 

+      const gfx::GpuMemoryBufferParams& params,

[reveman, 2014/05/27 22:46:01]

The idea I had for this IPC was that it would take a gfx::GpuMemoryBufferHandle
and the usual parameters (width, height..). The handle is created by the browser
process and might not be more than a unique id from a browser controlled
namespace (See gfx::SurfaceTextureId).

The browser is still in control over what type of buffer to allocate. The
creation of that specific GpuMemoryBuffer type just happens to be done on the
gpu process side.

The existing CreateImage IPC is replaced by a new type of GpuMemoryBuffer where
a gfx::GpuMemoryBufferHandle contains a valid gfx::PluginWindowHandle.

Some types might allocate the actual storage when creating a GpuMemoryBuffer on
GPU process side (ie. SurfaceTexture) others can create a GpuMemoryBuffer from
an existing allocation (ie. gfx::PluginWindowHandle). Hence, the name
Create/Destroy instead of Allocate.

[alexst (slow to review), 2014/05/28 14:18:57]

Got it.

+      const AllocateGpuMemoryBufferCallback& callback) OVERRIDE;
 
   // Specify a task runner and callback to be used for a set of messages. The
   // callback will be set up on the current GpuProcessHost, identified by
@@ -86,6 +89,16 @@ class CONTENT_EXPORT BrowserGpuChannelHostFactory
   static void AddFilterOnIO(int gpu_host_id,
                             scoped_refptr<IPC::MessageFilter> filter);
 
+  void AllocateGpuMemoryBufferAsyncOnIO(
+      const gfx::GpuMemoryBufferParams& params,
+      const AllocateGpuMemoryBufferCallback& callback);
+  static void GpuMemoryBufferAllocatedAsyncOnIO(
+      const AllocateGpuMemoryBufferCallback&,
+      const gfx::GpuMemoryBufferHandle& handle);
+  static void GpuMemoryBufferAllocatedAsync(
+      const AllocateGpuMemoryBufferCallback&,
+      const gfx::GpuMemoryBufferHandle& handle);
+
   const int gpu_client_id_;
   scoped_ptr<base::WaitableEvent> shutdown_event_;
   scoped_refptr<GpuChannelHost> gpu_channel_;