Fix resize issues when using threaded compositing

content/renderer/render_widget.cc

 // Copyright (c) 2011 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/renderer/render_widget.h"
 
 #include "base/command_line.h"
 #include "base/debug/trace_event.h"
 #include "base/logging.h"
 #include "base/memory/scoped_ptr.h"
@@ skipping 950 matching lines @@
   TRACE_EVENT0("gpu", "RenderWidget::didDeactivateCompositor");
 
   is_accelerated_compositing_active_ = false;
   Send(new ViewHostMsg_DidActivateAcceleratedCompositing(
       routing_id_, is_accelerated_compositing_active_));
 
   if (using_asynchronous_swapbuffers_)
     using_asynchronous_swapbuffers_ = false;
 }
 
+void RenderWidget::didCommitAndDrawCompositorFrame()
+{
+}
+
+void RenderWidget::didCompleteSwapbuffers()

[nduca, 2011/11/12 03:22:06]

Should this be conditional on compositor thread mode? Or do we not send this
when the CCSingleThreadProxy is active? We need to eventually call this all the
time, is there any #ifdef we should put in here to anticipate that behavior
change and avoid having to do a triple-commit?

[enne (OOO), 2011/11/12 19:29:19]

This function is robust to being called multiple times.  So, you should be able
to remove the render view pointer and things should Just Work (TM).

+{
+  if (!next_paint_flags_ && !plugin_window_moves_.size())
+    return;
+
+  ViewHostMsg_UpdateRect_Params params;
+  params.view_size = size_;
+  params.resizer_rect = resizer_rect_;
+  params.plugin_window_moves.swap(plugin_window_moves_);
+  params.flags = next_paint_flags_;
+  params.scroll_offset = GetScrollOffset();
+  update_reply_pending_ = true;
+
+  Send(new ViewHostMsg_UpdateRect(routing_id_, params));
+  next_paint_flags_ = 0;
+}
+
 void RenderWidget::scheduleComposite() {
   if (WebWidgetHandlesCompositorScheduling())
     webwidget_->composite(false);
   else {
     // TODO(nduca): replace with something a little less hacky.  The reason this
     // hack is still used is because the Invalidate-DoDeferredUpdate loop
     // contains a lot of host-renderer synchronization logic that is still
     // important for the accelerated compositing case. The option of simply
     // duplicating all that code is less desirable than "faking out" the
     // invalidation path using a magical damage rect.
@@ skipping 494 matching lines @@
   }
 }
 
 bool RenderWidget::WillHandleMouseEvent(const WebKit::WebMouseEvent& event) {
   return false;
 }
 
 bool RenderWidget::WebWidgetHandlesCompositorScheduling() const {
   return false;
 }