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

content/browser/renderer_host/render_widget_host_view_aura.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/renderer_host/render_widget_host_view_aura.h"
 
 #include "base/bind.h"
 #include "base/bind_helpers.h"
 #include "base/logging.h"
 #include "base/memory/weak_ptr.h"
@@ skipping 642 matching lines @@
 
 void RenderWidgetHostViewAura::AcceleratedSurfaceRelease(
     uint64 surface_handle) {
   if (current_surface_ == surface_handle) {
     current_surface_ = 0;
     UpdateExternalTexture();
   }
   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);
   window_->layer()->SetFillsBoundsOpaquely(background.isOpaque());
 }
 
 void RenderWidgetHostViewAura::GetScreenInfo(WebKit::WebScreenInfo* results) {
   GetScreenInfoForWindow(results, window_);
 }
 
@@ skipping 642 matching lines @@
 RenderWidgetHostView* RenderWidgetHostView::CreateViewForWidget(
     RenderWidgetHost* widget) {
   return new RenderWidgetHostViewAura(widget);
 }
 
 // static
 void content::RenderWidgetHostViewPort::GetDefaultScreenInfo(
     WebKit::WebScreenInfo* results) {
   GetScreenInfoForWindow(results, NULL);
 }