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

diff --git a/chrome/browser/browser_window.h b/chrome/browser/browser_window.h
index 1b382ae..2809d2e 100644
--- a/chrome/browser/browser_window.h
+++ b/chrome/browser/browser_window.h
@@ -83,7 +83,7 @@ class BrowserWindow {
 
   // TODO(beng): REMOVE?
   // Returns true if the frame is maximized (aka zoomed).
-  virtual bool IsMaximized() = 0;
+  virtual bool IsMaximized() const = 0;
 
   // Returns the location bar.
   virtual LocationBar* GetLocationBar() const = 0;
@@ -102,6 +102,12 @@ class BrowserWindow {
   // Returns whether the bookmark bar is visible or not.
   virtual bool IsBookmarkBarVisible() const = 0;
 
+  // Returns the rect where the resize corner should be drawn by the render
+  // widget host view (on top of what the renderer returns). We return an empty
+  // rect to identify that there shouldn't be a resize corner (in the cases
+  // where we take care of it ourselves at the browser level).
+  virtual gfx::Rect GetRootWindowResizerRect() const = 0;
+
   // Shows or hides the bookmark bar depending on its current visibility.
   virtual void ToggleBookmarkBar() = 0;
 
@@ -126,7 +132,7 @@ class BrowserWindow {
 
   // Shows the Import Bookmarks & Settings dialog box.
   virtual void ShowImportDialog() = 0;
-  
+
   // Shows the Search Engines dialog box.
   virtual void ShowSearchEnginesDialog() = 0;