Closed
Bug 724476
Opened 11 years ago
Closed 11 years ago
WebGL noticeably slower recently on Firefox 12 & 13 with D3D9
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
VERIFIED
FIXED
mozilla13
People
(Reporter: jonrandy, Assigned: jgilbert)
References
Details
(Keywords: regression, Whiteboard: [qa+])
Attachments
(5 files, 3 obsolete files)
1018 bytes,
patch
|
bjacob
:
review+
|
Details | Diff | Splinter Review |
3.12 KB,
patch
|
bjacob
:
review+
|
Details | Diff | Splinter Review |
2.15 KB,
patch
|
jgilbert
:
review+
|
Details | Diff | Splinter Review |
4.34 KB,
patch
|
jgilbert
:
review+
|
Details | Diff | Splinter Review |
9.43 KB,
patch
|
bjacob
:
review+
akeybl
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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
WebGL Firefox 10 is still getting 15fps although WebGL sometimes does not seem to initialise correctly
Comment 2•11 years ago
|
||
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
Updated•11 years ago
|
Component: Graphics → Canvas: WebGL
QA Contact: thebes → canvas.webgl
Comment 3•11 years ago
|
||
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 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
Updated•11 years ago
|
Keywords: regressionwindow-wanted
(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•11 years ago
|
||
Yes, the mozilla-central builds.
Comment 7•11 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•11 years ago
|
||
Forgot to mention, I can reproduce the described Restored/Maximized window dance with a new profile as well.
![]() |
||
Comment 9•11 years ago
|
||
Maybe duplication of Bug 725747
![]() |
||
Comment 10•11 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
Reporter | ||
Comment 11•11 years ago
|
||
I was just about to start trying to pin down where it went bad.... looks like I don't need to now?
Comment 12•11 years ago
|
||
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•11 years ago
|
||
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•11 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•11 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•11 years ago
|
||
according Comment 15,
No longer blocks: 720467
Keywords: regression → regressionwindow-wanted
Version: 13 Branch → 12 Branch
![]() |
||
Comment 17•11 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•11 years ago
|
tracking-firefox12:
--- → ?
tracking-firefox13:
--- → ?
Updated•11 years ago
|
Assignee: nobody → jgilbert
Updated•11 years ago
|
Assignee | ||
Comment 18•11 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•11 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•11 years ago
|
||
This is an ANGLE bug: http://code.google.com/p/angleproject/issues/detail?id=293
Attachment #598019 -
Flags: review?(bjacob)
Assignee | ||
Comment 21•11 years ago
|
||
This is an ANGLE bug: http://code.google.com/p/angleproject/issues/detail?id=294
Attachment #598021 -
Flags: review?(bjacob)
Assignee | ||
Comment 22•11 years ago
|
||
Both patches together are running on try at: https://tbpl.mozilla.org/?tree=Try&rev=51e6adba8282
Assignee | ||
Comment 23•11 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.
Reporter | ||
Comment 24•11 years ago
|
||
Try build is back up to speed - performing well as it used to :)
Updated•11 years ago
|
Attachment #598019 -
Flags: review?(bjacob) → review+
Comment 25•11 years ago
|
||
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+
Comment 26•11 years ago
|
||
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•11 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•11 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•11 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•11 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•11 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•11 years ago
|
||
Attachment #599333 -
Flags: review?(bjacob)
Assignee | ||
Comment 33•11 years ago
|
||
Attachment #599334 -
Flags: review?(bjacob)
Comment 34•11 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 35•11 years ago
|
||
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 36•11 years ago
|
||
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•11 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•11 years ago
|
||
Carrying r+ forward.
Attachment #599333 -
Attachment is obsolete: true
Attachment #599770 -
Flags: review+
Assignee | ||
Comment 39•11 years ago
|
||
Carrying r+ forward.
Attachment #599334 -
Attachment is obsolete: true
Attachment #599773 -
Flags: review+
Assignee | ||
Comment 40•11 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•11 years ago
|
Target Milestone: --- → mozilla13
Comment 41•11 years ago
|
||
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
Closed: 11 years ago
Resolution: --- → FIXED
Comment 42•11 years ago
|
||
Will this be backported to firefox 12?
Assignee | ||
Comment 43•11 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•11 years ago
|
||
[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•11 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 46•11 years ago
|
||
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 47•11 years ago
|
||
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?
Comment 48•11 years ago
|
||
Just set the a= field.
Assignee | ||
Comment 49•11 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•11 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•11 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
Comment 52•11 years ago
|
||
(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•11 years ago
|
Attachment #601152 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
Assignee | ||
Comment 53•11 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.
Comment 54•11 years ago
|
||
(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•11 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•11 years ago
|
Attachment #601152 -
Flags: approval-mozilla-aurora- → approval-mozilla-aurora?
Comment 56•11 years ago
|
||
(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•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
Assignee | ||
Comment 59•11 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)?
Comment 60•11 years ago
|
||
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•11 years ago
|
||
Testing on Windows XP with current Firefox Beta build: FPS: 34 with d3d9 FPS: 33 without d3d9 Same machine specs as comment 57.
Updated•11 years ago
|
Target Milestone: --- → mozilla13
Comment 62•11 years ago
|
||
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•11 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 64•11 years ago
|
||
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•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/74c3521374f9
status-firefox12:
--- → fixed
status-firefox13:
--- → fixed
Comment 66•11 years ago
|
||
Is qawanted still needed on this bug? If so, what is the specific ask for QA?
Assignee | ||
Comment 67•11 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.
Comment 68•11 years ago
|
||
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•11 years ago
|
||
No one objected to my comment 22 so dropping qawanted. Please re-add if there's something specific needed.
Keywords: qawanted
Comment 70•11 years ago
|
||
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•11 years ago
|
||
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).
Reporter | ||
Comment 72•11 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•11 years ago
|
||
File a new bug as it seems you have no problem in 13.0.1.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•