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/views/download_shelf_view.h b/chrome/browser/views/download_shelf_view.h
index 35213a8..3f157a4 100644
--- a/chrome/browser/views/download_shelf_view.h
+++ b/chrome/browser/views/download_shelf_view.h
@@ -31,7 +31,7 @@ class DownloadShelfView : public views::View,
                           public views::LinkController,
                           public AnimationDelegate {
  public:
-  DownloadShelfView(TabContents* tab_contents);
+  explicit DownloadShelfView(TabContents* tab_contents);
 
   // A new download has started, so add it to our shelf.
   void AddDownload(DownloadItem* download);
@@ -68,6 +68,12 @@ class DownloadShelfView : public views::View,
   // one.
   void ChangeTabContents(TabContents* old_contents, TabContents* new_contents);
 
+  // The browser view needs to know when we are going away to properly return
+  // the resize corner size to WebKit so that we don't draw on top of it.
+  // This returns the showing state of our animation which is set to false at
+  // the beginning Show and true at the beginning of a Hide.
+  bool IsShowing() const;
+
  private:
   void Init();
 
@@ -107,5 +113,5 @@ class DownloadShelfView : public views::View,
   DISALLOW_EVIL_CONSTRUCTORS(DownloadShelfView);
 };
 
-#endif // CHROME_BROWSER_VIEWS_DOWNLOAD_SHELF_VIEW_H__
+#endif  // CHROME_BROWSER_VIEWS_DOWNLOAD_SHELF_VIEW_H__