724476 - WebGL noticeably slower recently on Firefox 12 & 13 with D3D9

Status: VERIFIED FIXED

Description

[jonrandy]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20100101 Firefox/10.0
Build ID: 20120129021758

Steps to reproduce:

I regularly check https://webglsamples.googlecode.com/hg/aquarium/aquarium.html as a test of WebGL speed and functionality when trying Aurora and Nightly builds

Win XP SP3

Adapter Description			Mobile Intel(R) 965 Express Chipset Family
Vendor							ID8086
Device							ID2a02
Adapter RAM						Unknown
Adapter Driver					sigxprd32
Driver Version					6.14.10.5218
Driver Date						1-13-2010
Vendor ID (GPU #2)			8086
Device ID (GPU #2)			2a03
Adapter RAM (GPU #2)			Unknown
Adapter Drivers (GPU #2)	Unknown
Driver Version (GPU #2)		6.14.10.5218
Driver Date (GPU #2)			1-13-2010
WebGL Renderer					Google Inc. -- ANGLE (Mobile Intel(R) 965 Express Chipset Family) -- OpenGL ES 2.0 (ANGLE 0.0.0.809)
GPU Accelerated Windows		2/2 Direct3D 9



Actual results:

I cannot pinpoint an exact date, but for a while now WebGL does not seem to run as fast as it used to - I used to get about 15fps all the time. Now however, this has dropped to 7 or 8fps - this occurs even with a clean profile


Expected results:

I would expect WebGL performance as development continues would remain the same or (ideally) improve

Comment 1

[jonrandy]

WebGL Firefox 10 is still getting 15fps although WebGL sometimes does not seem to initialise correctly

Comment 2

[Kevin Brosnan [:kbrosnan]]

Maybe a ANGLE upgrade slowed things down. Someone from the graphics team may be able to point out dates where ANGLE was upgraded. Then test http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ around that date.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Jon, it would be incredibly useful if you could bisect this using archived Nightly builds found at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

Kevin, while it's possible that a ANGLE update would regress WebGL performance, it's also possible that the culprit is in our WebGL implementation per se, or in adjacent gfx code. Let's just bisect this for now.

Comment 4

[Zéfling]

I also note this regression.

Windows XP 64 SP2, WebGL Aquarium :
Fx 10 : ~60 FPS
Fx 13 : 1~2 FPS


Description de la carte   ATI Radeon HD 4600 Series
ID du vendeur             0x1002
ID du périphérique        0x9490
RAM de la carte           Unknown 
Pilotes de la carte       ati2dvag
Version du pilote         8.930.0.0
Date du pilote            12-5-2011
Rendu Web                 GLGoogle Inc. -- 
                          ANGLE (ATI Radeon HD 4600 Series) -- 
                          OpenGL ES 2.0 (ANGLE 1.0.0.963)
Fenêtres avec AC          1/1 Direct3D 9

Comment 5

[jonrandy]

(In reply to Benoit Jacob [:bjacob] from comment #3)
> Jon, it would be incredibly useful if you could bisect this using archived
> Nightly builds found at:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
> 
> Kevin, while it's possible that a ANGLE update would regress WebGL
> performance, it's also possible that the culprit is in our WebGL
> implementation per se, or in adjacent gfx code. Let's just bisect this for
> now.

I should be able to do this this weekend - what builds should I be looking at? mozilla-central builds from the 2012/01 2012/02 folders?

Comment 6

[Benoit Jacob [:bjacob] (mostly away)]

Yes, the mozilla-central builds.

Comment 7

[Mauro Sanabria]

I have noticed the slowness first with Inspector's 3D View (embedded Tilt); after some experimenting in my setup (Fx 12.0a2 32-bit on Windows 7 64-bit, Mobile Intel 965 Express -blocked, only Direct3D 9 available-) I found it also happens with other WebGL demos and got STR and a workaround: the problem manifests only when the WebGL application is started with a maximized window, and it doesn't when started from a restored window.

I have yet to try starting the WebGL application from a fullscreen window (cannot test with Inspector's 3D View due to bug 694000, bug 705197 and because keyboard shortcuts for Inspector's buttons are not recognized in fullscreen). Nevertheless, when the WebGL application is started from a restored window it remains fast when it is maximized or fullscreened afterwards; conversely, when it is started from a maximized window it remains slow if the window is restored or fullscreened afterwards.

In my setup the problem manifests with all my 24 add-ons enabled, and with all of them manually disabled (one by one) as well; however, if you do Help->Restart with Add-ons Disabled... the problem does not manifest.

Hope this helps...

Comment 8

[Mauro Sanabria]

Forgot to mention, I can reproduce the described Restored/Maximized window dance with a new profile as well.

Comment 9

[Alice0775 White]

Maybe duplication of Bug 725747

Comment 10

[Alice0775 White]

Regression window(m-c)
Last good:
http://hg.mozilla.org/mozilla-central/rev/3c1cdbbea964
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120207 Firefox/13.0a1 ID:20120207010203
First bad:
http://hg.mozilla.org/mozilla-central/rev/2b61af9d18ee
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120207 Firefox/13.0a1 ID:20120207023403
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3c1cdbbea964&tochange=2b61af9d18ee





Regression window(m-i)
Last good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/e2db006298c2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120206 Firefox/13.0a1 ID:20120206185103
First bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/fa92500f4ad2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120206 Firefox/13.0a1 ID:20120206191607
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e2db006298c2&tochange=fa92500f4ad2


Triggered by: Bug 720467

Comment 11

[jonrandy]

I was just about to start trying to pin down where it went bad.... looks like I don't need to now?

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Jon: comment 10 is conclusive that the regression is caused by the patches from bug 720467, but that implies that it's a regression in Firefox 13, not in Firefox 12 as you originally reported. If you are positive that there's a regression in Firefox 12 already, then comment 10 is talking about a separate thing and you own bisecting would then still be useful.

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

The regression found by comment 10, caused by bug 720467, is quite possibly/probably bug 725747, which has a patch pending review.

Comment 14

[Mark Funk]

It seems that this slowness is caused by Angle.

Inspector's 3D view started when browser is maximized:
In Firefox 11: Fluid
In Current m-c: sub 1FPS
In Current m-c with webgl.prefer-native-gl true: Fluid

I can also confirm Comment 7

Inspector's 3D view started when browser is not maximized:
In Firefox 11: Fluid
In Current m-c: Fluid
In Current m-c with webgl.prefer-native-gl true: Fluid


Tested with Radeon Mobile 6370 On Windows 7 64bit with 32bit builds of Firefox

Comment 15

[jonrandy]

OK - last good nightly build for me is the one from 26th Jan which was still version 12. WebGL on all subsequent builds is almost half as fast

Comment 16

[Alice0775 White]

according Comment 15,

Comment 17

[Alice0775 White]

This problem happens  if layers.prefer-d3d9 = true;

Regression window(m-c)
Works:
http://hg.mozilla.org/mozilla-central/rev/7cdb5f5d38c6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126093130
Slow
http://hg.mozilla.org/mozilla-central/rev/a82c9700c673
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126151450
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7cdb5f5d38c6&tochange=a82c9700c673



Regression window(m-i)
Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/9effde68bac5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126091747
Slow
http://hg.mozilla.org/integration/mozilla-inbound/rev/fccccb47213e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126092751
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9effde68bac5&tochange=fccccb47213e


Triggered by 
fccccb47213e	Jeff Gilbert — Bug 721205 - Add correct logic for enabling BGRA readPixels for GLES - r=bjacob

Comment 18

[Jeff Gilbert [:jgilbert]]

So this is a couple of ANGLE bugs:
http://code.google.com/p/angleproject/issues/detail?id=293
http://code.google.com/p/angleproject/issues/detail?id=294

This bug also severely impacts performance on d3d10 as well, though d3d9 should be being hit even harder.

Try build at:
https://tbpl.mozilla.org/?tree=Try&rev=51e6adba8282

Comment 19

[MrX1980]

I don't think this is a ANGLE (only) problem, because Aurora and Nightly has the same ANGLE version .963

http://www.kamibu.com/demos/cloth-simulation/
Aurora (12.0a2) = fast
Nightly (13.0a1) = slow

The only different I can see is gfx.direct3d.prefer_10_1
Aurora = gfx.direct3d.prefer_10_1 not exist
Nightly = gfx.direct3d.prefer_10_1 is always true and cannot set to false (switching always back to true after restart)

Google Inc. -- ANGLE (NVIDIA GeForce GT 240) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)

Comment 20

[Jeff Gilbert [:jgilbert]]

Created attachment 598019 [details] [diff] [review]
Patch 1: Enforce readPixels format/type spec

This is an ANGLE bug: http://code.google.com/p/angleproject/issues/detail?id=293

Comment 21

[Jeff Gilbert [:jgilbert]]

Created attachment 598021 [details] [diff] [review]
Patch 2: Expose BGRA as ANGLE fast-path

This is an ANGLE bug:
http://code.google.com/p/angleproject/issues/detail?id=294

Comment 22

[Jeff Gilbert [:jgilbert]]

Both patches together are running on try at:
https://tbpl.mozilla.org/?tree=Try&rev=51e6adba8282

Comment 23

[Jeff Gilbert [:jgilbert]]

(In reply to MrX1980 from comment #19)
> I don't think this is a ANGLE (only) problem, because Aurora and Nightly has
> the same ANGLE version .963
> 
> http://www.kamibu.com/demos/cloth-simulation/
> Aurora (12.0a2) = fast
> Nightly (13.0a1) = slow
> 
> The only different I can see is gfx.direct3d.prefer_10_1
> Aurora = gfx.direct3d.prefer_10_1 not exist
> Nightly = gfx.direct3d.prefer_10_1 is always true and cannot set to false
> (switching always back to true after restart)
> 
> Google Inc. -- ANGLE (NVIDIA GeForce GT 240) -- OpenGL ES 2.0 (ANGLE
> 1.0.0.963)

I believe this is bug 726396, which new appears to be distinct from this d3d9 layers bug.

Comment 24

[jonrandy]

Try build is back up to speed - performing well as it used to :)

Comment 25

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 598021 [details] [diff] [review]
Patch 2: Expose BGRA as ANGLE fast-path

Review of attachment 598021 [details] [diff] [review]:
-----------------------------------------------------------------

What should be committed to upstream ANGLE?

Comment 26

[Benoit Jacob [:bjacob] (mostly away)]

Also: since these patches are to our copy of ANGLE, it is very important to add them as gfx/angle/*.patch files and mention them in gfx/angle/README.mozilla. Otherwise, if for some reason they're not accepted upstream, we'd lose them the next time we sync.

Comment 27

[daniel-bzmz]

(In reply to Jeff Gilbert [:jgilbert] from comment #20)
> Created attachment 598019 [details] [diff] [review]
> Patch 1: Enforce readPixels format/type spec
> 
> This is an ANGLE bug:
> http://code.google.com/p/angleproject/issues/detail?id=293

As I explained in Issue 293, I don't believe this change is correct.

Comment 28

[daniel-bzmz]

(In reply to Jeff Gilbert [:jgilbert] from comment #21)
> Created attachment 598021 [details] [diff] [review]
> Patch 2: Expose BGRA as ANGLE fast-path
> 
> This is an ANGLE bug:
> http://code.google.com/p/angleproject/issues/detail?id=294

I would consider accepting this patch.  I don't believe it should rely on the previous patch.  Ideally the approach in mainline would be as described in Issue 295 (http://code.google.com/p/angleproject/issues/detail?id=295), but this is likely better a better value for default IMPLEMENTATION READ FORMAT/TYPE until we get there.

Comment 29

[daniel-bzmz]

Perhaps the biggest question though, is why is the ReadPixels path now being taken?  It certainly wasn't before as we have not changed this area of ANGLE.  In general read-pixels is not a well-optimized path in ANGLE, and likely will never be the best path. I thought that the ReadPixels path wasn't required under ANGLE (with the d3d9-share handles, etc).  Note that we also provide support for ANGLE_framebuffer_blit which can do much more efficient copies.

Comment 30

[Jeff Gilbert [:jgilbert]]

(In reply to daniel-bzmz from comment #29)
> Perhaps the biggest question though, is why is the ReadPixels path now being
> taken?  It certainly wasn't before as we have not changed this area of
> ANGLE.  In general read-pixels is not a well-optimized path in ANGLE, and
> likely will never be the best path. I thought that the ReadPixels path
> wasn't required under ANGLE (with the d3d9-share handles, etc).  Note that
> we also provide support for ANGLE_framebuffer_blit which can do much more
> efficient copies.

It was an issue with the patch for bug 720467, which will be fixed in bug 726396 which I will be uploading later today. There was some incorrect logic that was preventing the share handles from being used.

Comment 31

[Jeff Gilbert [:jgilbert]]

I would like to keep Patch 1's strict interpretation in our downstream version. It seems we've hit on a more strict implementation over at bug 728724, but it could be spurious.

Comment 32

[Jeff Gilbert [:jgilbert]]

Created attachment 599333 [details] [diff] [review]
Patch 1.5: Add Patch 1 to ANGLE patches

Comment 33

[Jeff Gilbert [:jgilbert]]

Created attachment 599334 [details] [diff] [review]
Patch 2.5: Add Patch 2 to ANGLE patches

Comment 34

[daniel-bzmz]

(In reply to Jeff Gilbert [:jgilbert] from comment #31)
> I would like to keep Patch 1's strict interpretation in our downstream
> version. It seems we've hit on a more strict implementation over at bug
> 728724, but it could be spurious.
IMO ANGLE being less restrictive shouldn't have any impact on that, since ANGLE won't be used there...

Comment 35

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 599333 [details] [diff] [review]
Patch 1.5: Add Patch 1 to ANGLE patches

Review of attachment 599333 [details] [diff] [review]:
-----------------------------------------------------------------

r=me but you also need to mention it in gfx/angle/README.mozilla

Comment 36

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 599334 [details] [diff] [review]
Patch 2.5: Add Patch 2 to ANGLE patches

Review of attachment 599334 [details] [diff] [review]:
-----------------------------------------------------------------

r=me but you also need to mention it in gfx/angle/README.mozilla

Comment 37

[Jeff Gilbert [:jgilbert]]

(In reply to daniel-bzmz from comment #34)
> (In reply to Jeff Gilbert [:jgilbert] from comment #31)
> > I would like to keep Patch 1's strict interpretation in our downstream
> > version. It seems we've hit on a more strict implementation over at bug
> > 728724, but it could be spurious.
> IMO ANGLE being less restrictive shouldn't have any impact on that, since
> ANGLE won't be used there...

It's not used there, but if ANGLE were equally restrictive, we would have caught these bugs earlier.

Comment 38

[Jeff Gilbert [:jgilbert]]

Created attachment 599770 [details] [diff] [review]
Patch 1.5: Add Patch 1 to ANGLE patches

Carrying r+ forward.

Comment 39

[Jeff Gilbert [:jgilbert]]

Created attachment 599773 [details] [diff] [review]
Patch 2.5: Add Patch 2 to ANGLE patches

Carrying r+ forward.

Comment 40

[Jeff Gilbert [:jgilbert]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/59f92448d122
https://hg.mozilla.org/integration/mozilla-inbound/rev/ecab589f11f6
https://hg.mozilla.org/integration/mozilla-inbound/rev/388d3a2c8f12
https://hg.mozilla.org/integration/mozilla-inbound/rev/b4d48afb5859

Comment 41

[Marco Bonardo [::mak]]

https://hg.mozilla.org/mozilla-central/rev/59f92448d122
https://hg.mozilla.org/mozilla-central/rev/ecab589f11f6
https://hg.mozilla.org/mozilla-central/rev/388d3a2c8f12
https://hg.mozilla.org/mozilla-central/rev/b4d48afb5859

Comment 42

[Mathieu Pellerin]

Will this be backported to firefox 12?

Comment 43

[Jeff Gilbert [:jgilbert]]

(In reply to Mathieu Pellerin from comment #42)
> Will this be backported to firefox 12?

Hopefully yes. The patches were fairly simple, so it should be relatively easy to backport.

Comment 44

[Jeff Gilbert [:jgilbert]]

Created attachment 601152 [details] [diff] [review]
Fix ANGLE to readPixels better with BGRA

[Approval Request Comment]
Regression caused by (bug #): 721205
User impact if declined: Severely compromised WebGL performance, mostly on WinXP.
Testing completed (on m-c, etc.): On m-c and by QA.
Risk to taking this patch (and alternatives if risky): Low risk: Problem is now well understood and the fix is simple.
String changes made by this patch: None

Asking bjacob for a r+ on this folded combinations of the previous patches to play it extra-safe.

Comment 45

[Jeff Gilbert [:jgilbert]]

Comment on attachment 601152 [details] [diff] [review]
Fix ANGLE to readPixels better with BGRA

Regression was in 12, so only backporting to aurora is needed.

Comment 46

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 601152 [details] [diff] [review]
Fix ANGLE to readPixels better with BGRA

Review of attachment 601152 [details] [diff] [review]:
-----------------------------------------------------------------

Does seem to match. Side note: there is a severe bug... in bugzilla's diff viewer, when viewing the .patch files, it omits some of the line adds.

Comment 47

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 601152 [details] [diff] [review]
Fix ANGLE to readPixels better with BGRA

In fact we also want that for beta! For bug 723444.

[Approval Request Comment]
Regression caused by (bug #): don't know... some ANGLE upgrade? jgilbert might know
User impact if declined: WebGL very slow on certain/many Windows systems (I reproduceded on Windows XP in bug 723444).
Testing completed (on m-c, etc.): It's on m-c already. I tested myself on beta on WinXP.
Risk to taking this patch (and alternatives if risky): possibly introduce another WebGL perf regression.
String changes made by this patch: none

Comment 48

[Benoit Jacob [:bjacob] (mostly away)]

Created attachment 601430 [details] [diff] [review]
patch ready to land on beta

Just set the a= field.

Comment 49

[Jeff Gilbert [:jgilbert]]

This shouldn't do anything to beta, since the patch it's built on (Bug 721205) landed in 12.

Comment 50

[Jeff Gilbert [:jgilbert]]

Comment on attachment 601152 [details] [diff] [review]
Fix ANGLE to readPixels better with BGRA

Bug that needs beta review is Bug 727178.

Comment 51

[Jeff Gilbert [:jgilbert]]

Comment on attachment 601430 [details] [diff] [review]
patch ready to land on beta

This patch should be unnecessary, since we correctly use BGRA readpixels on ANGLE (though for invalid reasons) before the logic was corrected in the patch that landed on Fx12, exposing this regression.

Changing this in ANGLE on Fx11/Beta shouldn't change anything, but it shouldn't fix anything either, I think.

Comment 52

[Alex Keybl [:akeybl]]

(In reply to Jeff Gilbert [:jgilbert] from comment #51)
> This patch should be unnecessary, since we correctly use BGRA readpixels on
> ANGLE (though for invalid reasons) before the logic was corrected in the
> patch that landed on Fx12, exposing this regression.

Adding qawanted to see whether or not this regression is necessary on the latest Aurora 12 builds now that we've fixed bug 727178. Please re-nominate if not.

Comment 53

[Jeff Gilbert [:jgilbert]]

Specifically, they should check WebGL performance on WinXP. Without this patch, performance should be majorly impacted, since the patch that regressed this from bug 721205 landed on 12.

Comment 54

[Alex Keybl [:akeybl]]

(In reply to Alex Keybl [:akeybl] from comment #52)
> Adding qawanted to see whether or not this regression is necessary on the
> latest Aurora 12 builds now that we've fixed bug 727178. Please re-nominate
> if not.

s/necessary/fixed/

(In reply to Jeff Gilbert [:jgilbert] from comment #53)
> Specifically, they should check WebGL performance on WinXP. Without this
> patch, performance should be majorly impacted, since the patch that
> regressed this from bug 721205 landed on 12.

Sorry, could you clarify whether you believe FF12 has poor performance with D3D9 without this patch? I took "This patch should be unnecessary" from your previous comment to mean we were unsure if it was necessary at all.

Comment 55

[Jeff Gilbert [:jgilbert]]

Perhaps I was too weak in my wording. This patch fixes a regression from a commit which hit Fx12. Since we are quite sure that this caused the regression, we can be quite sure that this fix is also needed on 12. That is, unless testing shows Fx12 perf was not degraded by the regression in question in this bug.

In other words, Fx12 almost certainly needs this regression fix for those using d3d9 layers and ANGLE, which is mostly WinXP users. Without this backport, ANGLE performance will be (relatively severely) negatively impacted relative to the size of the canvas.

Comment 56

[Alex Keybl [:akeybl]]

(In reply to Jeff Gilbert [:jgilbert] from comment #55)
> That
> is, unless testing shows Fx12 perf was not degraded by the regression in
> question in this bug.

Just pinged QA to verify whether the patch is necessary.

Comment 57

[Jason Smith [:jsmith]]

Tested on Windows XP latest FF 12 Aurora build (12.0a2)

FPS: 8 with D3D9 Enabled
FPS: 8 without D3D9

Adapter: NVIDIA Quadro FX 3450/4000 SDI
WebGL Render: Google nc. -- ANGLE (NVIDIA Quadro FX 3450/4000 SDI) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)
GPU Accelerated Windows: 1/1 Direct 3D 9

Comment 58

[Jason Smith [:jsmith]]

Note: Above was tested with the aquarium at 50 fishes.

Also tested this on Windows XP with the 2/7/2012 Aurora build of Firefox and saw the same performance in comment 57.

Comment 59

[Jeff Gilbert [:jgilbert]]

(In reply to Jason Smith from comment #58)
> Note: Above was tested with the aquarium at 50 fishes.
> 
> Also tested this on Windows XP with the 2/7/2012 Aurora build of Firefox and
> saw the same performance in comment 57.

How does this compare to trunk performance (should have been fixed) or FF 11 perf (before regression window)?

Comment 60

[Jason Smith [:jsmith]]

Testing on Windows XP with the current Nightly build

FPS: 33 without d3d9
FPS: 33 with d3d9

Same machine specs as comment 57.

Comment 61

[Jason Smith [:jsmith]]

Testing on Windows XP with current Firefox Beta build:

FPS: 34 with d3d9
FPS: 33 without d3d9

Same machine specs as comment 57.

Comment 62

[Alex Keybl [:akeybl]]

Jeff - based upon QA's testing, is this still necessary on Aurora 12? If so, we'll approve so that you can land tomorrow.

Comment 63

[Jeff Gilbert [:jgilbert]]

(In reply to Alex Keybl [:akeybl] from comment #62)
> Jeff - based upon QA's testing, is this still necessary on Aurora 12? If so,
> we'll approve so that you can land tomorrow.

Yes, this is still necessary.
QA has nightly/13 and beta/11 at 33fps, while aurora/12 is at 8fps.
This is also a low-risk patch, so landing should be uneventful.

Comment 64

[Alex Keybl [:akeybl]]

Comment on attachment 601152 [details] [diff] [review]
Fix ANGLE to readPixels better with BGRA

[Triage Comment]
Approved for Aurora 12 since this is a regression in that version.

Comment 65

[Jeff Gilbert [:jgilbert]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/74c3521374f9

Comment 66

[Anthony Hughes (:ashughes) [GFX][QA][Mentor]]

Is qawanted still needed on this bug? If so, what is the specific ask for QA?

Comment 67

[Jeff Gilbert [:jgilbert]]

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #66)
> Is qawanted still needed on this bug? If so, what is the specific ask for QA?

As in Comment 4, probably WebGL Aquarium, or any WebGL demo with a large screen that displays framerate. The regression will cause extreme framerate reductions in relation to the size of the canvas. (near-fullscreen demos should be most affected) Complexity of demo doesn't matter too much; Aquarium with the least number of fishes should be tremendously slow with this regression. (pre-fix)

Note that this is with D3D9 layers and ANGLE WebGL renderer.

Comment 68

[Anthony Hughes (:ashughes) [GFX][QA][Mentor]]

If I understand comment 67 correctly, all that is needed at this point is fix verification. If that's that case, we can drop qawanted.

Comment 69

[Anthony Hughes (:ashughes) [GFX][QA][Mentor]]

No one objected to my comment 22 so dropping qawanted. Please re-add if there's something specific needed.

Comment 70

[Simona Badau [Away. Please needinfo? Alin Deac [:alindeac]]]

Verified with Firefox 12 beta 2 on Windows XP having D3D9 enabled and Angle WebGL render - on the WebGL Aquarium demo (https://webglsamples.googlecode.com/hg/aquarium/aquarium.html) the frame rate is 30.

Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0

Comment 71

[Simona Badau [Away. Please needinfo? Alin Deac [:alindeac]]]

Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0

Verified using Firefox 13 beta 2 that having D3D9 enabled and Angle WebGl render  the fps is 30 (tested on https://webglsamples.googlecode.com/hg/aquarium/aquarium.html).

Comment 72

[jonrandy]

Has there been a regression here? Just updated Nightly to 30/06/2012 and aquarium page is running about half the speed. Not sure if this happened with this update or 1 or 2 days back as have not tested for a couple of days

Comment 73

[Scoobidiver (away)]

File a new bug as it seems you have no problem in 13.0.1.