Drop frontbuffers with ui-use-gpu-process, synchronized with browser, decoupled from backbuffer dro…

content/browser/renderer_host/render_widget_host_view_aura.cc

Index: content/browser/renderer_host/render_widget_host_view_aura.cc
diff --git a/content/browser/renderer_host/render_widget_host_view_aura.cc b/content/browser/renderer_host/render_widget_host_view_aura.cc
index 6850ebd13809f70a7a33f34ca13f2c8b5e943611..6162f71b7a297f23953466d85ff6f71eceae9417 100644
--- a/content/browser/renderer_host/render_widget_host_view_aura.cc
+++ b/content/browser/renderer_host/render_widget_host_view_aura.cc
@@ -660,6 +660,21 @@ void RenderWidgetHostViewAura::AcceleratedSurfaceRelease(
   image_transport_clients_.erase(surface_handle);
 }
 
+void RenderWidgetHostViewAura::AcceleratedSurfaceSuggestDiscard(
+    uint64 surface_handle, int32 route_id, int gpu_host_id) {
+  if (host_->IsVisible() && current_surface_ == surface_handle)
+    return;

[piman, 2012/05/04 00:03:49]

The problem here is that it's racy. We may miss an opportunity to drop the front
buffer when switching tabs rapidly.

[mmocny, 2012/05/04 18:55:52]

Very sorry, but I am still not understanding why there would be a missed
opportunity.
We will only request a drop if not visible, so if visible here, it must be a
stale request.

Also, stepping back a bit from the specifics here, the overall notion of missing
some opportunity to listen to a suggestion from the GpuMemoryManager is not
generally a problem because it will continue to "Manage" and continue to send
you suggestions if you aren't in the state it expects.  Obviously we want to be
correct and efficient, but if there is a temporary racy window here, it is
better to be cautious and wait for the next suggestion to come in.

+
+  AcceleratedSurfaceRelease(surface_handle);
+
+  on_compositing_ended_callbacks_.push_back(

[piman, 2012/05/04 00:03:49]

on_compositing_ended_callbacks_ may not be used unless we've added ourselves as
a compositor observer. Right now only do that on Swap/Post and in some resize
cases.
You probably want to change that so that we're always an observer while we're
visible.
The other thing is, you only want to delay the sending if the surface is
actually in use (i.e. between OnCompositingStarted and OnCompositingEnded).

[mmocny, 2012/05/04 18:55:52]

Once I stop scheduling a composite, Yes, I'll need to add as an observer. Thanks
for pointing that out.

On 2012/05/04 00:03:49, piman wrote:

+      base::Bind(&RenderWidgetHostImpl::SendSurfaceDiscard,

[piman, 2012/05/04 00:03:49]

By the time that callback is called, we may be visible again, in which case you
shouldn't drop the surface. Better call a method on this object, and only then
send the message if we're still invisible.

[mmocny, 2012/05/04 18:55:52]

Correct, thanks!
On 2012/05/04 00:03:49, piman wrote:

+                 surface_handle,
+                 route_id,
+                 gpu_host_id));
+  host_->ScheduleComposite();

[piman, 2012/05/04 00:03:49]

This shouldn't be needed. If we don't have a frame pending, we don't want to
kick one just to know when it's done so that we can send the message. See above,
if you take OnCompositingStarted into account, you don't need this.

+}
+
 void RenderWidgetHostViewAura::SetBackground(const SkBitmap& background) {
   content::RenderWidgetHostViewBase::SetBackground(background);
   host_->SetBackground(background);