diff options
author | jamesr@chromium.org <jamesr@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-02-07 22:16:42 +0000 |
---|---|---|
committer | jamesr@chromium.org <jamesr@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-02-07 22:16:42 +0000 |
commit | 05a980d7adcbde16a13f196ef7a9653bee4696f5 (patch) | |
tree | b865799ed4435a154ec327116d50d0f9f3120245 /chrome/browser/ui/browser_browsertest.cc | |
parent | 09dd31796a3164c6564c900586194aec7957189d (diff) | |
download | chromium_src-05a980d7adcbde16a13f196ef7a9653bee4696f5.zip chromium_src-05a980d7adcbde16a13f196ef7a9653bee4696f5.tar.gz chromium_src-05a980d7adcbde16a13f196ef7a9653bee4696f5.tar.bz2 |
Defer render_widget draw until host window is available
In accelerated compositing mode we can't start rendering until the
native window (HWND/gtk widget) are created on Windows and GTK without
aura. For most render_widgets the code today is racy, but for
window.open() and similar creation paths this is a race that we pretty
much always lose. This defers the first DoDeferredUpdate on a render_widget
until its host_window_ is available.
Also defers querying for GL_CHROMIUM_supports_swapbuffers_callback
extension until the first draw, since the context isn't ready until the
host window is available.
BUG=106815
TEST=start with --force-compositing-mode and --show-fps-counter, load up
a page that uses window.open() to open a popup, and confirm that the
popup is in compositing mode
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=119977
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=120111
Review URL: https://chromiumcodereview.appspot.com/9225050
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@120839 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/ui/browser_browsertest.cc')
0 files changed, 0 insertions, 0 deletions