summaryrefslogtreecommitdiffstats
path: root/gfx
diff options
context:
space:
mode:
authorthakis@chromium.org <thakis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-11-18 17:44:26 +0000
committerthakis@chromium.org <thakis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-11-18 17:44:26 +0000
commit65d52b9b218a016bb62067b3d495d430a7d4b3af (patch)
tree9bd40f192fa89c9db5733db5f60f904ce98cdbb0 /gfx
parent06bdc8d8e8f82f75034f45dd032abbae2a787024 (diff)
downloadchromium_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