diff options
| author | mad@chromium.org <mad@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-02-12 14:46:17 +0000 |
|---|---|---|
| committer | mad@chromium.org <mad@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-02-12 14:46:17 +0000 |
| commit | f21c613a0ab52b707f8a2effacda74c77f4448ea (patch) | |
| tree | 09051d286db764a71b97bc01f35765e607b4d20f /chrome/chrome.sln | |
| parent | 822cfc93fe52974b904b7f184c5448dee5d281c5 (diff) | |
| download | chromium_src-f21c613a0ab52b707f8a2effacda74c77f4448ea.zip chromium_src-f21c613a0ab52b707f8a2effacda74c77f4448ea.tar.gz chromium_src-f21c613a0ab52b707f8a2effacda74c77f4448ea.tar.bz2 | |
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
Diffstat (limited to 'chrome/chrome.sln')
| -rwxr-xr-x | chrome/chrome.sln | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/chrome/chrome.sln b/chrome/chrome.sln index e2491fb..16776a7 100755 --- a/chrome/chrome.sln +++ b/chrome/chrome.sln @@ -1795,6 +1795,7 @@ Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "browser_views", "browser\vi Release.AspNetCompiler.Debug = "False" EndProjectSection ProjectSection(ProjectDependencies) = postProject + {0B469837-3D46-484A-AFB3-C5A6C68730B9} = {0B469837-3D46-484A-AFB3-C5A6C68730B9} {4052059A-D72B-4183-B5C2-9D1B099E9E35} = {4052059A-D72B-4183-B5C2-9D1B099E9E35} {D9DDAF60-663F-49CC-90DC-3D08CC3D1B28} = {D9DDAF60-663F-49CC-90DC-3D08CC3D1B28} EndProjectSection |