Note: There are a few cases of duplicates in user autocompletion which are being worked on.

[ANGLE]Display flickers on certain webgl demo.

RESOLVED FIXED in Firefox 11

Status

()

Core
Canvas: WebGL
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Alice0775 White, Assigned: jgilbert)

Tracking

({regression})

11 Branch
mozilla13
x86
Windows 7
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox11 verified, firefox12 verified)

Details

(Whiteboard: [qa+], URL)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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
Keywords: fennecnative-betablocker
Keywords: fennecnative-betablocker
(Assignee)

Comment 1

6 years ago
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.
(Assignee)

Comment 2

6 years ago
Created attachment 600193 [details] [diff] [review]
Force ANGLE to use glFinish for resolve
Assignee: nobody → jgilbert
Status: NEW → ASSIGNED
Attachment #600193 - Flags: review?(bjacob)
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.
Attachment #600193 - Flags: review?(bjacob) → review-
(Assignee)

Comment 4

6 years ago
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
Attachment #600193 - Flags: review- → review+
(Assignee)

Comment 7

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/791442d6d012
Target Milestone: --- → mozilla13
https://hg.mozilla.org/mozilla-central/rev/791442d6d012
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
status-firefox11: --- → affected
status-firefox12: --- → affected
Version: Trunk → 11 Branch

Updated

6 years ago
Duplicate of this bug: 722717
(Assignee)

Updated

6 years ago
Blocks: 723444
(Assignee)

Comment 10

6 years ago
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.
Attachment #600193 - Flags: approval-mozilla-beta?
Attachment #600193 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 11

6 years ago
Created attachment 601444 [details] [diff] [review]
Force ANGLE to use glFinish for resolve (beta)

Beta was too far back for the main patch to apply cleanly, so here's the beta version.
Attachment #601444 - Flags: review?(bjacob)
Attachment #601444 - Flags: approval-mozilla-beta?
(Assignee)

Updated

6 years ago
Attachment #600193 - Flags: approval-mozilla-beta?
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.
Attachment #600193 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Updated

6 years ago
Attachment #601444 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #601444 - Flags: review?(bjacob) → review+
(Assignee)

Comment 13

6 years ago
Fx12 Aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/55ee63484487
(Assignee)

Updated

6 years ago
status-firefox12: affected → fixed
(Assignee)

Comment 14

6 years ago
Fx11/Beta:
https://hg.mozilla.org/releases/mozilla-beta/rev/cefd93ce9ec5
status-firefox11: affected → fixed
Whiteboard: [qa+]
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.
status-firefox11: fixed → verified
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.
status-firefox12: fixed → verified
You need to log in before you can comment on or make changes to this bug.