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, 2 deletions

diff --git a/chrome/renderer/render_widget.h b/chrome/renderer/render_widget.h
index d4d92c4..56ba30c 100644
--- a/chrome/renderer/render_widget.h
+++ b/chrome/renderer/render_widget.h
@@ -120,7 +120,7 @@ class RenderWidget : public IPC::Channel::Listener,
   // RenderWidget IPC message handlers
   void OnClose();
   void OnCreatingNewAck(gfx::NativeViewId parent);
-  void OnResize(const gfx::Size& new_size);
+  void OnResize(const gfx::Size& new_size, const gfx::Rect& resizer_rect);
   void OnWasHidden();
   void OnWasRestored(bool needs_repainting);
   void OnPaintRectAck();
@@ -204,6 +204,9 @@ class RenderWidget : public IPC::Channel::Listener,
   // scroll event is pending.
   gfx::Rect scroll_rect_;
 
+  // The area that must be reserved for drawing the resize corner.
+  gfx::Rect resizer_rect_;
+
   // The scroll delta for a pending scroll event.
   gfx::Point scroll_delta_;
 
@@ -262,4 +265,4 @@ class RenderWidget : public IPC::Channel::Listener,
   DISALLOW_EVIL_CONSTRUCTORS(RenderWidget);
 };
 
-#endif // CHROME_RENDERER_RENDER_WIDGET_H__
+#endif  // CHROME_RENDERER_RENDER_WIDGET_H__