This is an attempt at finding the reason for the page_cycler slowness caused by

the new resize corner. Local experiment led me to believe that it is WebKit
that is slower when we specify a resize corner area.

To validate this hypothesis, I always return an empty rect to WebKit, but I
still compute and push the rect to the render widget and I also draw the bitmap
even if this will cause it to be drawn on top of the scroll bars when there is
only one.

TBR=brettw


git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9654 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 5 insertions, 3 deletions

diff --git a/chrome/common/render_messages_internal.h b/chrome/common/render_messages_internal.h
index 76e53c4..f61b122 100644
--- a/chrome/common/render_messages_internal.h
+++ b/chrome/common/render_messages_internal.h
@@ -70,9 +70,11 @@ IPC_BEGIN_MESSAGES(View)
   // Tells the render view to change its size.  A ViewHostMsg_PaintRect message
   // is generated in response provided new_size is not empty and not equal to
   // the view's current size.  The generated ViewHostMsg_PaintRect message will
-  // have the IS_RESIZE_ACK flag set.
-  IPC_MESSAGE_ROUTED1(ViewMsg_Resize,
-                      gfx::Size /* new_size */)
+  // have the IS_RESIZE_ACK flag set. It also receives the resizer rect so that
+  // we don't have to fetch it every time WebKit asks for it.
+  IPC_MESSAGE_ROUTED2(ViewMsg_Resize,
+                      gfx::Size /* new_size */,
+                      gfx::Rect /* resizer_rect */)
 
   // Sent to inform the view that it was hidden.  This allows it to reduce its
   // resource utilization.