HW video decode support for --enable-threaded-compositing

content/renderer/media/renderer_gpu_video_decoder_factories.h

Index: content/renderer/media/renderer_gpu_video_decoder_factories.h
diff --git a/content/renderer/media/renderer_gpu_video_decoder_factories.h b/content/renderer/media/renderer_gpu_video_decoder_factories.h
index 37359898d6ffa123259aba776ab42934113aefc8..044ffd61e8dfdeb58e9ad82dc111b257b5ec2b2c 100644
--- a/content/renderer/media/renderer_gpu_video_decoder_factories.h
+++ b/content/renderer/media/renderer_gpu_video_decoder_factories.h
@@ -14,7 +14,7 @@
 #include "ui/gfx/size.h"
 
 class GpuChannelHost;
-class ContentGLContext;
+class WebGraphicsContext3DCommandBufferImpl;
 namespace base {
 class WaitableEvent;
 }
@@ -25,15 +25,19 @@ class WaitableEvent;
 // implementation from render_view_impl.cc which is already far too large.
 //
 // The public methods of the class can be called from any thread, and are
-// internally trampolined to the thread on which the class was constructed
-// (de-facto, the renderer thread) if called from a different thread.
+// internally trampolined to the appropriate thread.  GPU/GL-related calls go to
+// the constructor-argument loop (mostly that's the compositor thread, or the
+// renderer thread if threaded compositing is disabled), and shmem-related calls
+// go to the render thread.
 class CONTENT_EXPORT RendererGpuVideoDecoderFactories
     : public media::GpuVideoDecoder::Factories {
  public:
   // Takes a ref on |gpu_channel_host| and tests |context| for NULL before each
   // use.
-  RendererGpuVideoDecoderFactories(GpuChannelHost* gpu_channel_host,
-                                   base::WeakPtr<ContentGLContext> context);
+  RendererGpuVideoDecoderFactories(
+      GpuChannelHost* gpu_channel_host,
+      MessageLoop* message_loop,
+      WebGraphicsContext3DCommandBufferImpl* wgc3dcbi);
 
   virtual media::VideoDecodeAccelerator* CreateVideoDecodeAccelerator(
       media::VideoDecodeAccelerator::Profile profile,
@@ -52,10 +56,11 @@ class CONTENT_EXPORT RendererGpuVideoDecoderFactories
   virtual ~RendererGpuVideoDecoderFactories();
 
  private:
-  // Async versions of the public methods.  These all run on |message_loop_|
-  // exclusively, and use output parameters instead of return values.  Finally,
-  // each takes a WaitableEvent* param to signal completion (except for
-  // DeleteTexture, which is fire-and-forget).
+  // Async versions of the public methods.  They use output parameters instead
+  // of return values and each takes a WaitableEvent* param to signal completion
+  // (except for DeleteTexture, which is fire-and-forget).
+  // AsyncCreateSharedMemory runs on the renderer thread and the rest run on
+  // |message_loop_|.
   void AsyncCreateVideoDecodeAccelerator(
       media::VideoDecodeAccelerator::Profile profile,
       media::VideoDecodeAccelerator::Client* client,
@@ -70,7 +75,7 @@ class CONTENT_EXPORT RendererGpuVideoDecoderFactories
 
   MessageLoop* message_loop_;
   scoped_refptr<GpuChannelHost> gpu_channel_host_;
-  base::WeakPtr<ContentGLContext> context_;
+  WebGraphicsContext3DCommandBufferImpl* wgc3dcbi_;

[no sievers, 2012/03/08 20:09:27]

What about the WGC3D going away?
Not only during context lost, but what about races with shutdown and such?

[Ami GONE FROM CHROMIUM, 2012/03/08 20:19:51]

Dunno.  James?
(in practice these races will be rare as this class is mostly involved in
setup/teardown, not steady-state playback)

[no sievers, 2012/03/08 21:16:16]

If you still use the WeakPtr to the ContentGLContext, I guess you'd avoid the
problem (as long as you check it for being valid any time you dereference it
obviously).

[Ami GONE FROM CHROMIUM, 2012/03/08 21:22:27]

Actually isn't it enough to know that this member is only dereferenced on the
compositor thread's loop?  I.e. is it possible the WGC3D goes away while the
compositor's loop is still processing tasks?

   DISALLOW_IMPLICIT_CONSTRUCTORS(RendererGpuVideoDecoderFactories);
 };