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, 4 insertions, 0 deletions

diff --git a/chrome/common/temp_scaffolding_stubs.h b/chrome/common/temp_scaffolding_stubs.h
index 428acdd..1f17cc9 100644
--- a/chrome/common/temp_scaffolding_stubs.h
+++ b/chrome/common/temp_scaffolding_stubs.h
@@ -596,6 +596,10 @@ class TabContentsDelegate {
     NOTIMPLEMENTED();
     return true;
   }
+  virtual gfx::Rect GetRootWindowResizerRect() const {
+    return gfx::Rect();
+  }
+
   virtual bool IsExternalTabContainer() {
     NOTIMPLEMENTED();
     return false;