diff options
author | thakis@chromium.org <thakis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-11-18 17:44:26 +0000 |
---|---|---|
committer | thakis@chromium.org <thakis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-11-18 17:44:26 +0000 |
commit | 65d52b9b218a016bb62067b3d495d430a7d4b3af (patch) | |
tree | 9bd40f192fa89c9db5733db5f60f904ce98cdbb0 /gfx | |
parent | 06bdc8d8e8f82f75034f45dd032abbae2a787024 (diff) | |
download | chromium_src-65d52b9b218a016bb62067b3d495d430a7d4b3af.zip chromium_src-65d52b9b218a016bb62067b3d495d430a7d4b3af.tar.gz chromium_src-65d52b9b218a016bb62067b3d495d430a7d4b3af.tar.bz2 |
Mac: Only clear the background of CoreAnimation plugins if we're going to draw into them.
Previously, the logic was:
1.) Clear plugin background
2.) If the plugin didn't update, return early
3.) Paint plugin
4.) "Swap buffers"
But the "Swap buffers" step only unbound and rebound an FBO object If the plugin didn't change, its backing store would contain transparent black, and if the graphics driver decided to flush the FBO for another reason than a "swap buffers" call, the blackness would show up in the browser.
This CL swaps steps 1 and 2, so even if the FBO is flushed for some unrelated reason, we display something valid.
BUG=60341
TEST=Open the file attached to the bug. Resize the window for a few minutes, put the computer to sleep and back on, resize window for a few more minutes. The plugin area (the 191x60px rect in the middle) shouldn't become black. YouTube should still work. CPU usage shouldn't be worse than it was before for the browser, plugin, and renderer processes.
Review URL: http://codereview.chromium.org/5220002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66631 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'gfx')
0 files changed, 0 insertions, 0 deletions