Command to mark surface inactive, so gpu process can release resources.

content/common/gpu/image_transport_surface.h

Index: content/common/gpu/image_transport_surface.h
diff --git a/content/common/gpu/image_transport_surface.h b/content/common/gpu/image_transport_surface.h
index 044d8c3231e0c67cf8c01ed8b24f5dbc4ca69a23..5e7b414173be3ba73433cbb7c575a4bb5f5d7d2b 100644
--- a/content/common/gpu/image_transport_surface.h
+++ b/content/common/gpu/image_transport_surface.h
@@ -52,6 +52,7 @@ class ImageTransportSurface {
       uint64 surface_id, TransportDIB::Handle surface_handle) = 0;
   virtual void OnBuffersSwappedACK() = 0;
   virtual void OnResize(gfx::Size size) = 0;
+  virtual void OnSurfaceVisible(bool visible) = 0;
 
   // Creates the appropriate surface depending on the GL implementation.
   static scoped_refptr<gfx::GLSurface>
@@ -105,6 +106,9 @@ class ImageTransportHelper : public IPC::Channel::Listener {
   // Backbuffer resize callback.
   void Resize(gfx::Size size);
 
+  // Backbuffer visibility change callback.
+  void SurfaceVisible(bool visible);

[apatrick_chromium, 2011/10/07 22:45:49]

I'm still not clear why you want to add a new GL command? It seems you could
sidestep a lot of plumbing via the decoder by just sending an async IPC to this
object and having this function handle it? Is the sender not able to determine
the routing routing ID? Preceding it with an async flush will ensure that it is
not reordered relative to prior and subsequent GL commands.

[mmocny, 2011/10/11 13:58:43]

You are correct.
First I thought it would not be possible with IPC, and then that it might
slightly less efficient (glflush+IPC+(possibly)command stream flush).
Now I am wondering if it means more WebKit plumbing, and I am investigating.
I will update this CL with either a new implementation, or a reason why not.

On 2011/10/07 22:45:49, apatrick_chromium wrote:

+
   // Weak pointers that point to objects that outlive this helper.
   ImageTransportSurface* surface_;
   GpuChannelManager* manager_;