Delete background tab IOSurfaces on Mac.

content/browser/gpu/gpu_process_host.h

Index: content/browser/gpu/gpu_process_host.h
diff --git a/content/browser/gpu/gpu_process_host.h b/content/browser/gpu/gpu_process_host.h
index f101c6c3d4ff940708b24da479df589db44e1705..90c43b060547c9a91a1706b4d47a9872a91d8565 100644
--- a/content/browser/gpu/gpu_process_host.h
+++ b/content/browser/gpu/gpu_process_host.h
@@ -29,6 +29,7 @@ struct GpuHostMsg_AcceleratedSurfacePostSubBuffer_Params;
 struct GpuHostMsg_AcceleratedSurfaceRelease_Params;
 
 class BrowserChildProcessHostImpl;
+class RenderWidgetHelper;
 
 class GpuProcessHost : public content::BrowserChildProcessHostDelegate,
                        public IPC::Message::Sender,
@@ -95,6 +96,12 @@ class GpuProcessHost : public content::BrowserChildProcessHostDelegate,
 
   void ForceShutdown();
 
+  void RegisterRenderWidgetHelper(
+      int render_process_id,
+      const scoped_refptr<RenderWidgetHelper>& render_widget_helper);
+
+  void UnregisterRenderWidgetHelper(int render_process_id);
+
  private:
   static bool HostIsValid(GpuProcessHost* host);
 
@@ -117,6 +124,10 @@ class GpuProcessHost : public content::BrowserChildProcessHostDelegate,
   void OnCommandBufferCreated(const int32 route_id);
   void OnDestroyCommandBuffer(int32 surface_id);
 
+#if defined(OS_MACOSX)
+  void OnAcceleratedSurfaceBuffersSwapped(
+      const GpuHostMsg_AcceleratedSurfaceBuffersSwapped_Params& params);
+#endif
 #if defined(OS_WIN) && !defined(USE_AURA)
   void OnAcceleratedSurfaceBuffersSwapped(
       const GpuHostMsg_AcceleratedSurfaceBuffersSwapped_Params& params);
@@ -188,6 +199,8 @@ class GpuProcessHost : public content::BrowserChildProcessHostDelegate,
 
   scoped_ptr<BrowserChildProcessHostImpl> process_;
 
+  std::map<int, scoped_refptr<RenderWidgetHelper> > render_widget_helpers_;

[piman, 2012/04/18 21:07:44]

Is this map really necessary? There's already a renderer_process_id ->
RenderProcessHost map  (through RenderProcessHost::FromID) and
RenderProcessHostImpl owns the widget_helper_

I'm also concerned about that a GpuProcessHost might outlive a
RenderWidgetHelper and still receive straggler messages for it, but that
RenderWidgetHelper wouldn't have unregistered from this GpuProcessHost because
it had to talk to a new GPU process.

[jbates, 2012/04/18 23:01:58]

Sadly RenderProcessHost::FromID is UI thread only with a DCHECK to enforce.
I'm not sure I'm following this scenario. The refptr prevents the GpuProcessHost
from outliving the RenderWidgetHelper. When is there a new GPU process while the
old GpuProcessHost remains?

[piman, 2012/04/18 23:32:22]

You can have >1 GpuProcessHost because the teardown of a GPU process is
asynchronous. See GpuMessageFilter::OnEstablishGpuChannel and in particular
GpuProcessHost::FromID for cases were we return NULL (therefore creating a new
one) while there are still some that are live.

I missed the scoped_refptr but I wonder if it may extend the lifetime of the
RenderWidgetHelper beyond what's expected (it has some raw back pointers). Maybe
you've already thought about these issues and it's all fine?

[jbates, 2012/04/19 01:24:18]

Hmm, a scoped_refptr with an externally owned raw pointer member == guaranteed
fun! I'll track down the usage of resource_dispatcher_host_ to see if there are
any problems.

+
   DISALLOW_COPY_AND_ASSIGN(GpuProcessHost);
 };