WebGL noticeably slower recently on Firefox 12 & 13 with D3D9

VERIFIED FIXED in Firefox 12

Status

()

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

People

(Reporter: jonrandy, Assigned: jgilbert)

Tracking

(Blocks: 1 bug, {regression})

12 Branch
mozilla13
x86
Windows XP
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox12+ verified, firefox13+ verified)

Details

(Whiteboard: [qa+])

Attachments

(5 attachments, 3 obsolete attachments)

(Reporter)

Description

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

Comment 1

6 years ago
WebGL Firefox 10 is still getting 15fps although WebGL sometimes does not seem to initialise correctly
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.
Component: Untriaged → Graphics
Product: Firefox → Core
QA Contact: untriaged → thebes
Component: Graphics → Canvas: WebGL
QA Contact: thebes → canvas.webgl
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

5 years ago
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
Keywords: regressionwindow-wanted
(Reporter)

Comment 5

5 years ago
(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?
Yes, the mozilla-central builds.

Comment 7

5 years ago
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

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

Comment 9

5 years ago
Maybe duplication of Bug 725747

Comment 10

5 years ago
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
Blocks: 720467
Keywords: regressionwindow-wanted → regression
Version: 12 Branch → 13 Branch
(Reporter)

Comment 11

5 years ago
I was just about to start trying to pin down where it went bad.... looks like I don't need to now?
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.
The regression found by comment 10, caused by bug 720467, is quite possibly/probably bug 725747, which has a patch pending review.
Depends on: 725747

Comment 14

5 years ago
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
(Reporter)

Comment 15

5 years ago
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

5 years ago
according Comment 15,
No longer blocks: 720467
Keywords: regression → regressionwindow-wanted
Version: 13 Branch → 12 Branch

Comment 17

5 years ago
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
Blocks: 721205
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regressionwindow-wanted → regression
Summary: WebGL noticeably slower recently on Firefox 12 & 13 → [d3d9] WebGL noticeably slower recently on Firefox 12 & 13

Updated

5 years ago
tracking-firefox12: --- → ?
tracking-firefox13: --- → ?
Assignee: nobody → jgilbert

Updated

5 years ago
tracking-firefox12: ? → +
tracking-firefox13: ? → +
(Assignee)

Comment 18

5 years ago
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
Status: NEW → ASSIGNED
Summary: [d3d9] WebGL noticeably slower recently on Firefox 12 & 13 → WebGL noticeably slower recently on Firefox 12 & 13

Comment 19

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

Comment 20

5 years ago
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
Attachment #598019 - Flags: review?(bjacob)
(Assignee)

Comment 21

5 years ago
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
Attachment #598021 - Flags: review?(bjacob)
(Assignee)

Comment 22

5 years ago
Both patches together are running on try at:
https://tbpl.mozilla.org/?tree=Try&rev=51e6adba8282
(Assignee)

Comment 23

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

Updated

5 years ago
Blocks: 726396
(Reporter)

Comment 24

5 years ago
Try build is back up to speed - performing well as it used to :)
Attachment #598019 - Flags: review?(bjacob) → review+
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?
Attachment #598021 - Flags: review?(bjacob) → review+
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

5 years ago
(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

5 years ago
(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

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

Comment 30

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

Comment 31

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

Comment 32

5 years ago
Created attachment 599333 [details] [diff] [review]
Patch 1.5: Add Patch 1 to ANGLE patches
Attachment #599333 - Flags: review?(bjacob)
(Assignee)

Comment 33

5 years ago
Created attachment 599334 [details] [diff] [review]
Patch 2.5: Add Patch 2 to ANGLE patches
Attachment #599334 - Flags: review?(bjacob)

Comment 34

5 years ago
(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 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
Attachment #599333 - Flags: review?(bjacob) → review+
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
Attachment #599334 - Flags: review?(bjacob) → review+
(Assignee)

Comment 37

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

Comment 38

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

Carrying r+ forward.
Attachment #599333 - Attachment is obsolete: true
Attachment #599770 - Flags: review+
(Assignee)

Comment 39

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

Carrying r+ forward.
Attachment #599334 - Attachment is obsolete: true
Attachment #599773 - Flags: review+
(Assignee)

Comment 40

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

Updated

5 years ago
Target Milestone: --- → mozilla13
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
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Blocks: 722717

Comment 42

5 years ago
Will this be backported to firefox 12?
(Assignee)

Comment 43

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

Comment 44

5 years ago
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.
Attachment #601152 - Flags: review?(bjacob)
Attachment #601152 - Flags: approval-mozilla-beta?
Attachment #601152 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 45

5 years ago
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.
Attachment #601152 - Flags: approval-mozilla-beta?
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.
Attachment #601152 - Flags: review?(bjacob) → review+
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
Attachment #601152 - Flags: approval-mozilla-beta?
Created attachment 601430 [details] [diff] [review]
patch ready to land on beta

Just set the a= field.
(Assignee)

Comment 49

5 years ago
This shouldn't do anything to beta, since the patch it's built on (Bug 721205) landed in 12.
Summary: WebGL noticeably slower recently on Firefox 12 & 13 → WebGL noticeably slower recently on Firefox 12 & 13 with D3D9
(Assignee)

Comment 50

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

Bug that needs beta review is Bug 727178.
Attachment #601152 - Flags: approval-mozilla-beta?
(Assignee)

Comment 51

5 years ago
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.
Attachment #601430 - Attachment is obsolete: true
(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.
Keywords: qawanted

Updated

5 years ago
Attachment #601152 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
(Assignee)

Comment 53

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

Comment 55

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

Updated

5 years ago
Blocks: 723444
(Assignee)

Updated

5 years ago
Attachment #601152 - Flags: approval-mozilla-aurora- → approval-mozilla-aurora?
(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.
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
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.
(Assignee)

Updated

5 years ago
No longer blocks: 721205
Depends on: 721205
Target Milestone: mozilla13 → ---
(Assignee)

Comment 59

5 years ago
(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)?
Testing on Windows XP with the current Nightly build

FPS: 33 without d3d9
FPS: 33 with d3d9

Same machine specs as comment 57.
Testing on Windows XP with current Firefox Beta build:

FPS: 34 with d3d9
FPS: 33 without d3d9

Same machine specs as comment 57.

Updated

5 years ago
Target Milestone: --- → mozilla13
Jeff - based upon QA's testing, is this still necessary on Aurora 12? If so, we'll approve so that you can land tomorrow.
(Assignee)

Comment 63

5 years ago
(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 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.
Attachment #601152 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 65

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/74c3521374f9
status-firefox12: --- → fixed
status-firefox13: --- → fixed
Is qawanted still needed on this bug? If so, what is the specific ask for QA?
(Assignee)

Comment 67

5 years ago
(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.
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.
Whiteboard: [qa+]
No one objected to my comment 22 so dropping qawanted. Please re-add if there's something specific needed.
Keywords: qawanted
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
status-firefox12: fixed → verified
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).
status-firefox13: fixed → verified
(Reporter)

Comment 72

5 years ago
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 73

5 years ago
File a new bug as it seems you have no problem in 13.0.1.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Status: RESOLVED → VERIFIED
(Assignee)

Updated

5 years ago
Blocks: 769929
You need to log in before you can comment on or make changes to this bug.