Fix residue left over from find bar when using accelerated compositing

content/browser/renderer_host/render_widget_host.cc

Index: content/browser/renderer_host/render_widget_host.cc
diff --git a/content/browser/renderer_host/render_widget_host.cc b/content/browser/renderer_host/render_widget_host.cc
index cc1e9cf100101ae27f981bddc0b287cfbb9e2e3e..30ad1b023f4e88147ad8f657fd57f8feabb6121b 100644
--- a/content/browser/renderer_host/render_widget_host.cc
+++ b/content/browser/renderer_host/render_widget_host.cc
@@ -444,14 +444,6 @@ void RenderWidgetHost::ScheduleComposite() {
     repaint_ack_pending_ = true;
     Send(new ViewMsg_Repaint(routing_id_, current_size_));
   }
-
-  // When we have asked the RenderWidget to resize, and we are still waiting on
-  // a response, block for a little while to see if we can't get a response.
-  // We always block on response because we do not have a backing store.
-  IPC::Message msg;
-  TimeDelta max_delay = TimeDelta::FromMilliseconds(kPaintMsgTimeoutMS);
-  if (process_->WaitForUpdateMsg(routing_id_, max_delay, &msg))
-    OnMessageReceived(msg);

[jbates, 2011/05/27 17:11:41]

This blocking wait did not seem to have any effect in Linux. With or without,
dragging a window over chrome resulted in some minor white trails. Since it adds
more complexity (and has a race condition by design), it seems best to never
block until we can show a clear advantage.

[darin (slow to review), 2011/05/27 17:53:08]

won't this exacerbate the issue where the tab strip is out-of-sync with the tab
contents?  you switch tabs, but it still shows the old tab contents until
compositing eventually happens.  maybe we can add back some kind of blocking
like this to help synchronize the tab strip with the tab contents once we have a
better idea of what we need?

[jbates, 2011/05/27 18:18:55]

I think this code only subtly changes the behavior of switching tabs. With
blocking, the UI is blocked while waiting for the new tab to render for up to
40ms. If the new tab renders within 40ms, then the UI will update at about the
same time as the new tab view. If the tab takes too long, the UI will update
first, and then the tab view when it's finally rendered. In both cases, the new
tab only shows up when it's actually rendered. Since 40ms is not that long, I
think most people won't notice the difference when switching tabs. For those
that do notice the difference, they might prefer that the UI always responds
fast regardless of the content.

 }
 
 void RenderWidgetHost::StartHangMonitorTimeout(TimeDelta delay) {