Run VDA::Decode on GPU IO thread if VDA supports it.

content/common/gpu/gpu_channel.h

Index: content/common/gpu/gpu_channel.h
diff --git a/content/common/gpu/gpu_channel.h b/content/common/gpu/gpu_channel.h
index 0692b903b4fab7128f9c171a3c6a8dd24fcdc945..23c27e0a0a491333c1bee334dfa225e1fe31bcb8 100644
--- a/content/common/gpu/gpu_channel.h
+++ b/content/common/gpu/gpu_channel.h
@@ -86,6 +86,10 @@ class GpuChannel : public IPC::Listener,
 
   base::ProcessId renderer_pid() const { return channel_->peer_pid(); }
 
+  scoped_refptr<base::MessageLoopProxy> io_message_loop() const {

[Ami GONE FROM CHROMIUM, 2013/08/27 17:10:33]

I was not advocating for that (though I see no reason not to).
Instead, I was making the observation that the *VDA's themselves don't need to
be told what the IO loop is since they can get it for themselves.

[wuchengli, 2013/08/28 13:18:21]

I see what you mean now. I have tried to use
ChildProcess::current()->io_message_loop_proxy() in
GpuVideoDecodeAccelerator::Initialize. But DEPS did not allow to include
content/child from GpuVideoDecodeAccelerator.

+    return io_message_loop_;
+  }
+
   // IPC::Listener implementation:
   virtual bool OnMessageReceived(const IPC::Message& msg) OVERRIDE;
   virtual void OnChannelError() OVERRIDE;
@@ -156,6 +160,9 @@ class GpuChannel : public IPC::Listener,
 
   void CacheShader(const std::string& key, const std::string& shader);
 
+  void AddFilter(IPC::ChannelProxy::MessageFilter* filter);
+  void RemoveFilter(IPC::ChannelProxy::MessageFilter* filter);
+
  protected:
   virtual ~GpuChannel();