Closed Bug 754000 Opened 8 years ago Closed 3 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/15.0 Firefox/15.0a1 Build ID: 20120510030517 Steps to reproduce: Go to http://mbostock.github.com/d3/ex/voronoi.html and hover with your mouse over the applet. Happens in Linux x86 and Linux x64. Actual results: Bad performance, stuttering Expected results: It should've been a fluent experience like it is in Firefox 12
This worksforme on Mac, so may have to do with the usual path rendering mess. Need a regression range.... Requesting tracking for the regression.
Requested by Mardeg, this is from the x64 pc (Linux Mint Lisa): Graphics Adapter Description NVIDIA Corporation -- GeForce 9600M GT/PCIe/SSE2 Vendor ID NVIDIA Corporation Device ID GeForce 9600M GT/PCIe/SSE2 Driver Version 3.3.0 NVIDIA 295.20 WebGL Renderer NVIDIA Corporation -- GeForce 9600M GT/PCIe/SSE2 -- 3.3.0 NVIDIA 295.20 GPU Accelerated Windows 1/1 OpenGL AzureBackend skia Also tested with HWA disabled (which it is by default btw, I force enabled it), but I still get the same results.
wfm with Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/15.0 Firefox/15.0a1 SeaMonkey/2.12a1 (great build ID in the UA string :-( )
For me, with Firefox 12 on Windows the yellow shape resizes smoothly as the mouse moves about. With trunk the yellow shape resizes less frequently and therefore the movement appears somewhat jerky.
Aha! Robert, do you think you can hunt down a regression range?
bz: I am willing to hunt down the regression range too, but I don't have time until tomorrow. Sorry for not mentioning that before :)
There's no performance difference. It's an illusion... The application works quite differently in trunk and on 12. On trunk the yellow shape snaps to where the black lines on the diagram intersect each other on 12 it attaches to the lines rather than the intersection of lines and resizes smoothly along the lines. Do you not see this on a Mac? If not do you see the 12 or the trunk behaviour I'm describing.
I'll leave it to Tim to find the regression range. A reduced testcase would be nice to since it's a functional change rather than a performance issue.
FWIW Opera matches Firefox 12 for me.
On Mac, with both a 13 beta and a trunk nightly build, I see the behavior you describe as seeing in 12.
I think that is not true. If you move your mouse slowly on trunk, you'll see it intersects everywhere on the line. It might appear like it's only on the intersections, but that's because it creates new ones.
Perhaps you're right, if you move the mouse really slowly it does seem to go on the lines. It's not CPU bound on my machine though, it just doesn't seem to update very often.
Using mozregression to bisect, I found this to contain the regression: Last good nightly: 2012-03-21 First bad nightly: 2012-03-22 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-03-21&enddate=2012-03-22 So the regression is not in Firefox 13, but in Firefox 14. The reason why I thought I was seeing it in 13 too, is because somehow the build Ubuntu/Mint deliver in their repositories appears to be faster than Mozilla's (stable Firefox 12) download. So it's faster than the 13 beta too, which is about the same speed as FF 12. But there also appears to be a real regression. However, it is very hard to compare performance in a visual way if I can't view them side by side. But I switched back and forth multiple times and I actually think there is a performance difference between those builds. Robert: as you appear to be the only one who could reproduce, can you confirm this?
Well that makes a lot more sense. It must be bug 734079
Depends on: 734079
Version: 13 Branch → 14 Branch
Looks like it from that bisect range, although that bug doesn't actually show in it. The builds from before and after bug 734079 landed are (respectively): https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/03/2012-03-21-03-11-51-mozilla-central/ https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/03/2012-03-22-03-12-20-mozilla-central/ Tim, can you confirm that things work in the former, but not in the latter?
I can't see any regression at all even with the latest trunk if I use nightly builds. The only difference I see is when I compare with a self built debug trunk.
That's not entirely unexpected, since I added a fair bit of debug code in the patches for bug 734079. We only really care about the release build performance of course. If Tim can't reproduce using the builds linked in comment 15, then maybe we're looking at the wrong range.
it's quite possible, bug 734079 is just an educated guess at this point.
Well, I think there is a small difference indeed, but I can only confirm my last comment. It is hard to see a difference between those builds, but I switched between them multiple times and I think it is there. It is, however, not "the big regression". On exactly the same (clean) profile, Firefox downloaded from http://www.mozilla.org/en-US/firefox/fx/ is *very* noticeably slower than the one that comes preinstalled by Ubuntu/Mint, and that's why I thought this was such a big regression, which it isn't.
Perhaps there's some difference in compiler flags such that the preinstalled version is more tailored to your cpu? Are there differences in what about:buildconfig says about your Ubuntu installation compared to the standard Mozilla build?
Or maybe the ubuntu build is running hardware accelerated and the mozilla build isn't. Is there any difference in the graphics stuff at the end about:support
Adding qawanted - we should use the STR in comment 0 across the builds in comment 15 (where it broke) and builds around https://bugzilla.mozilla.org/show_bug.cgi?id=734079#c36 (where it may be fixed) on Mac/Linux. We'd like to understand whether this performance regression is visible in any way. Thanks!
http://mbostock.github.com/d3/ex/voronoi.html is working fine on FF 14b8 on Mac OS X 10.6. On Ubuntu 12.04 I see a very small deterioration between the builds from comment 15, and definetely a bigger one between nightly 2012-03-22 and FF 14b8. Anyway, I don't see a 100% smooth move neither in FF 12 (compared with FF 14b8 on Mac OS X 10.6 for e.g).
(In reply to Paul Silaghi [QA] from comment #23) > http://mbostock.github.com/d3/ex/voronoi.html is working fine on FF 14b8 on > Mac OS X 10.6. > > On Ubuntu 12.04 I see a very small deterioration between the builds from > comment 15, and definetely a bigger one between nightly 2012-03-22 and FF > 14b8. Anyway, I don't see a 100% smooth move neither in FF 12 (compared with > FF 14b8 on Mac OS X 10.6 for e.g). Can we get a regression window on Linux please? That'll help us resolve the regression.
(In reply to Alex Keybl [:akeybl] from comment #24) > (In reply to Paul Silaghi [QA] from comment #23) > > http://mbostock.github.com/d3/ex/voronoi.html is working fine on FF 14b8 on > > Mac OS X 10.6. > > > > On Ubuntu 12.04 I see a very small deterioration between the builds from > > comment 15, and definetely a bigger one between nightly 2012-03-22 and FF > > 14b8. Anyway, I don't see a 100% smooth move neither in FF 12 (compared with > > FF 14b8 on Mac OS X 10.6 for e.g). > > Can we get a regression window on Linux please? That'll help us resolve the > regression. Ever since FF 4. Tested on Ubuntu 11.10 and 12.04 32-bit.
And it's getting worse between the builds from comment 15 and still deteriorating after that until the latest nightly (I couldn't find a regression range for this, I think it's getting worse progressively in several times)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1 > Result is smooth with no lag whatsoever Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/14.0 Firefox/14.0a1 ID:20120314031139 > Lag is somewhat noticeable, this is the first 14.0 Nightly Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/14.0 Firefox/14.0a1 ID:20120401041203 > Lag is fairly evident at this point Given I can reproduce the lag in the first 14.0 Nightly and 13.0 is unaffected, I'm not sure where else to debug this.
Interestingly, I can also detect a very small lag in Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/13.0 Firefox/13.0a1 ID:20120301031135.
Firefox 13.0.1 comes pre-installed in my Ubuntu machine, and the example in comment #0 works really well. All versions I downloaded from our ftp servers and installed on the desktop, 4, 5, 10, 11, 12, 13, 13.0.1, 14 (as in comment #15), 14.0b11, or latest nightly, all 64bit versions, were noticeably slow. I don't know how to install previous versions of Fx on Ubuntu such as they were installed by default with the system, but if anyone knows how to do it, please ping me so I can give it a try.
Sorry for not replying here anymore, I was busy with exams and doing stuff for my youth movement :) The biggest difference is probably that Ubuntu compiles Firefox with GCC 4.6 instead of 4.5. I can attach the output of about:buildconfig here, but I'm not sure how you would like it (plaintext in a comment or as an attachment, as HTML, ...) and I guess it's not very hard to get it anyway :)
Tim, the best way would be a plain-text file attached to this bug (not as a comment), thanks.
Tim, would you be able to assist us in tracking down a regression range for this bug? We're having trouble tracking down a way to get older Ubuntu Firefox versions installed.
As far as I know, Ubuntu only provides the last Firefox version and the one that was the default on release date in its repository. So if you download Ubuntu 11.10, you can try Firefox 7. I think 12.04 packed Firefox 12.
Given my comment 27, I'm not convinced it's compiler related because all of our Linux builds use the same compiler. I think we need to work to narrow down the regression range between the very first Firefox 14.0 Nightly build and Firefox 13.0. I suppose it's possible that a regression got merged in from inbound, but I don't know how to look into this. I think we need to hand the ball off to a developer who knows this code.
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:17.0) Gecko/17.0 Firefox/17.0 I've downloaded the daily firefox ppa from Ubuntu (Nightly equivalent) and the app works as slow there as on any Firefox downloaded from ftp. It's installed in the same manner as the default Firefox that comes with Ubuntu, where the app works without problems. https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa Unless I'm missing something, this would mean that the Ubuntu versions of Firefox regressed somewhere as well, between 14 and 17. (In reply to Anthony Hughes, Mozilla QA (:ashughes) [OoO until July 31] from comment #35) > Given my comment 27, I'm not convinced it's compiler related because all of > our Linux builds use the same compiler. I think we need to work to narrow > down the regression range between the very first Firefox 14.0 Nightly build > and Firefox 13.0. I suppose it's possible that a regression got merged in > from inbound, but I don't know how to look into this. I've loaded the app with both Firefox 14.0.1 and 13.0.1, but can't spot a big difference between performance for those builds. Is the 13.0.1 mentioned in comment 27 the Ubuntu packed Firefox?
Virgil, can you please do some more comparative testing? What is your UX with the following builds: * Firefox 13.0.1, 14.0.1, 15.0b3, 17.0a1 from ftp.mo * Firefox 13.0.1, 14.0.1, 15.0b3, 17.0a1 from Ubuntu ppa
> * Firefox 13.0.1, 14.0.1, 15.0b3, 17.0a1 from ftp.mo I can't see any noticeable difference between these builds. There is a big lag when moving the pointer over the diagram in all of them. > * Firefox 13.0.1, 14.0.1, 15.0b3, 17.0a1 from Ubuntu ppa *Firefox 13.0.1 and 14.0.1 from Ubuntu PPA work ok - the planes are highlighted and updated, don't work as well as Chrome and Opera when the mouse is moved faster along the diagram though *Firefox 15beta, Aurora and Nightly - all behave badly, as all the ftp.mozilla builds http://vid.ly/5c3t4p - screencast showing comparative behavior of Chrome and 14.0.1 from Ubuntu http://vid.ly/5f6b1m - screencast showing behavior comparative behavior of Chrome and 15 beta from Ubuntu. This is Ubuntu 12.04 i686. Also tried disabling any other add-ons instaled with the software through the Software center(raster fonts, unity integration, browser plugin, gnome support). That didn't change the way the app behaved in any situation.
Based on comment 38, I would assume the regression in comparing Firefox versions to have occurred within Firefox 15 Nightly. In terms of competitive comparison to Chrome and Opera, the regression likely would have occurred in Firefox 13 Nightly or earlier. Can you investigate this any further Virgil?
I can reproduce in Windows7 with HWA disabled Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/3de967c4624c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120321 Firefox/14.0a1 ID:20120321025041 Bad: http://hg.mozilla.org/mozilla-central/rev/f10862ac3217 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120321 Firefox/14.0a1 ID:20120321033140 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3de967c4624c&tochange=f10862ac3217 Regression window(m-c) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/43cc4d6d160a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120320 Firefox/14.0a1 ID:20120320051441 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/34454de86833 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120320 Firefox/14.0a1 ID:20120320051642 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=43cc4d6d160a&tochange=34454de86833
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #39) > Based on comment 38, I would assume the regression in comparing Firefox > versions to have occurred within Firefox 15 Nightly. In terms of competitive > comparison to Chrome and Opera, the regression likely would have occurred in > Firefox 13 Nightly or earlier. > > Can you investigate this any further Virgil? This isn't a regression in Firefox builds (on Linux, at least). My comment was a follow-up on what already was investigated by Juan and Paul. To resume, I see the following on Ubuntu (same as Juan in comment 29): ----Firefox downloaded from mozilla ftp: *All* Firefox versions exhibit a laggy animation when moving the pointer over the diagram. (tested from 4.0.1 to current Nightly, going through 9, 13, 14, 15, 16). There might be very small differences, but the animation is not smooth in any case. ----When using Firefox builds from Ubuntu: 13.0.1 and 14.0.1 work fine (not as perfect as Chrome, but fine - see videos in comment 38) 15 beta, Aurora 16 and Nightly are as laggy as the Firefox versions If there isn't any other installation issue involved here, this issue is a regression in Firefox Ubuntu builds starting with 15. So that's the only regression involved here.
Maybe we should split the Linux and windows bugs... This never worked with Firefox builds. The only way to go would be to investigate what exact problem triggered the issue in Ubuntu builds, but that won't be as easy as bisecting with Firefox. After asking around on Ubuntu's chat, managed to get some links to archived versions: http://archive.ubuntu.com/ubuntu/pool/main/f/firefox/ http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu/pool/main/f/firefox-trunk/ But there don't seem to be archived versions of 14 Nightlies, though. If there is any directions to go from here, please advise. At the moment, there isn't much left to do.
Is there any difference in about:buildconfig in the compiler/configure options between Ubuntu 13/14 and 15/16? Note that about:buildconfig from Ubuntu 13/14 is attached to this bug already.
Can't see an y difference between the buildcongfig information. Exact asame arguments and compiler version.
Definitely not going to get to this for 15.
(In reply to Jonathan Watt [:jwatt] from comment #45) > Definitely not going to get to this for 15. Un-tracking for 15 then, we'll keep this on our radar for 16.
Whiteboard: [in-the-wild] [external-report]
Spun off bug 754000 to possibly continue investigating our performance.
Assignee: jwatt → nobody
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
(In reply to Jonathan Watt [:jwatt] from comment #47) > Spun off bug 754000 I mean I span off bug 1348781.
You need to log in before you can comment on or make changes to this bug.