Build Identifier: http://hg.mozilla.org/mozilla-central/rev/60edf587f4af Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120214 Firefox/13.0a1 ID:20120214031227 I notice a problem when test Bug 726936. Display flickers on certain webgl demo. webgl.prefer-native-gl=true (webgl.force-enabled=true if required) helps. Note: Due to Bug 725747, It is difficult to test this in Nightly13.0a1 1. Start Firefox with new profile and UA spoofing user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20100101 Firefox/9.0"); 2. Open http://highrise.nfb.ca/onemillionthtower/1mt_webgl.php 3. Wait loading page 100% and menu panel fade-in 4. Click "or JUST WATCH>>" link at the bottom of the menu panel 5. Wait around 10-15 sec Actual Results: Screen flickers Expected Results: Should not flicker Regression window(m-c) Works: http://hg.mozilla.org/mozilla-central/rev/cbb0233c7ba8 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111217 Firefox/11.0a1 ID:20111217031145 Fails: http://hg.mozilla.org/mozilla-central/rev/d4aad9645f77 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111217 Firefox/11.0a1 ID:20111217090244 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cbb0233c7ba8&tochange=d4aad9645f77 Regression window(m-i) Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/b407ff123b6f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111216 Firefox/11.0a1 ID:20111216140251 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/b88bac3a29ba Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111216 Firefox/11.0a1 ID:20111216144049 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b407ff123b6f&tochange=b88bac3a29ba In local build, First bad changeset 9ba4a7f652fb Last good changeset 84f4cb3c8b9e Regressed by: 9ba4a7f652fb Jeff Gilbert — Bug 705024 - Guarantee GLContexts are resolved properly - r=bjacob Graphics Adapter Description : ATI Radeon HD 4300/4500 Series Vendor ID : 0x1002 Device ID : 0x954f Adapter RAM : 512 Adapter Drivers : aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Driver Version : 8.930.0.0 Driver Date : 12-5-2011 Direct2D Enabled : true DirectWrite Enabled : true (6.1.7601.17563) ClearType Parameters : Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 200 WebGL Renderer : Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series) -- OpenGL ES 2.0 (ANGLE 1.0.0.963) GPU Accelerated Windows : 1/1 Direct3D 10 AzureBackend : direct2d

The WebGL Pasta demo at http://www.chromeexperiments.com/detail/webgl-pasta/?f=webgl displays incomplete rendering when running ANGLE, and this looks similar. (Flickering since most of the rendering here is actually 2d planes/images) It appears that ANGLE's glFlush is not capable of resolving our FBOs for the purposes of compositing like we thought. On the plus side, this is an easy fix, and doesn't appear to degrade performance.

Comment on attachment 600193 [details] [diff] [review] Force ANGLE to use glFinish for resolve Review of attachment 600193 [details] [diff] [review]: ----------------------------------------------------------------- This restores the old behavior of falling back to another provider when EGL fails, doesn't it? If !gl we fall back.

This patch doesn't change that logic. I wouldn't think we should /not/ fallback. I thought we just blacklisted WGL in general, and that's how we prevented it. If we don't want to fallback at all, we should change this code so reflect that. As it stands the whole idea is to allow fallback.

We didn't blacklist OpenGL in general, see widget/windows/GfxInfo.cpp. In fact, we use OpenGL on Optimus. We changed the logic there so that when EGL creation fails, we don't try anymore to fall back to WGL. My understanding of your patch is that it reverts that: now if gl==null, we'll fall back.

Comment on attachment 600193 [details] [diff] [review] Force ANGLE to use glFinish for resolve sorry, got confused by the nested if's

Comment on attachment 600193 [details] [diff] [review] Force ANGLE to use glFinish for resolve [Approval Request Comment] Regression caused by (bug #): Bug 705024. User impact if declined: Rendering may happen incorrectly (this bug) and apps may experience jankiness. (see Bug 723444) Testing completed (on m-c, etc.): On m-c. Risk to taking this patch (and alternatives if risky): Very low. The reason we didn't do this before was because we thought this is the 'slow' path, and we thought it was unnecessary. String changes made by this patch: None.

Beta was too far back for the main patch to apply cleanly, so here's the beta version.

Comment on attachment 600193 [details] [diff] [review] Force ANGLE to use glFinish for resolve [Triage Comment] Based upon the low risk evaluation and chance of more web regressions (outside of just bug 723444), approving for Aurora 12 and Beta 11. Please land asap to make it into beta 5.

Fx12 Aurora: https://hg.mozilla.org/releases/mozilla-aurora/rev/55ee63484487

Fx11/Beta: https://hg.mozilla.org/releases/mozilla-beta/rev/cefd93ce9ec5

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0 Verified on Windows 7 on Firefox 11 beta 6 using the STR from the Description - display does not flicker.

Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20100101 Firefox/12.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 Verified on Win 7 with Firefox 12 beta 2 using the STR from the Description - display does not flicker.