zero-copy: Clarify to allocate/destroy GpuMemoryBuffer on any thread and use it on the main thread o

content/common/gpu/gpu_channel_manager.cc

Index: content/common/gpu/gpu_channel_manager.cc
diff --git a/content/common/gpu/gpu_channel_manager.cc b/content/common/gpu/gpu_channel_manager.cc
index 3d98e58e7292bc3f3cd18a0253dabe647897ca68..af999a892d0d9914f7d4c7caca7cf6851bd02b4e 100644
--- a/content/common/gpu/gpu_channel_manager.cc
+++ b/content/common/gpu/gpu_channel_manager.cc
@@ -59,6 +59,8 @@ class GpuChannelManagerMessageFilter : public IPC::MessageFilter {
  protected:
   ~GpuChannelManagerMessageFilter() override {}
 
+  // The UI thread in the browser compositor must remain fast at all times.
+  // Bouncing off only GPU IO is the way to ensure that.

[no sievers, 2015/04/08 18:51:35]

nit: What is this exactly trying to say? That we are handling this on the IO
thread directly, since it's a synchronous method (and we don't want to block the
client for too long)?

[dshwang, 2015/04/09 04:06:18]

Main thread also can handle synchronous message while it requires IO->Main->IO
bouncing. I tried to move GpuMsg_CreateGpuMemoryBuffer handling to main thread
in patch set 1, but alexst@ rejected due to above reason.

I changed the comment to be more understandable.

  // GPU IO thread bounces off GpuMsg_CreateGpuMemoryBuffer message, because
  // the UI thread in the browser process must remain fast at all times.

   void OnCreateGpuMemoryBuffer(
       const GpuMsg_CreateGpuMemoryBuffer_Params& params) {
     TRACE_EVENT2("gpu",