Closed Bug 361754 Opened 16 years ago Closed 12 years ago
Bad scrolling performance with Cairo builds using large background-image
I noticed that scrolling on this site is kind of slow and taking a lot of cpu, using current trunk builds. I bet this is a cairo issue, just like bug 328380 was. I'll attach a testcase, that shows the issue. I'm not attaching the background-image of the site to the bug, since it is almost 1MB (!). I don't see this with a 2006-08-09 build, but I can see it with a 2006-08-10 build: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-08-09+04&maxdate=2006-08-10+05&cvsroot=%2Fcvsroot I suspect a regression from bug 343655.
Flags: blocking1.9? → blocking1.9-
Re-requestion blocking 1.9. I really think it's important that this would get fixed. Someone in bug 324819 mentions scrolling performance degradation at http://www.csszengarden.com/?cssfile=/202/202.css&page=0 and http://www.agecommunity.com/ I suspect it's related to this bug. I think many more people will notice that scrolling is slower on certain pages.
Flags: blocking1.9- → blocking1.9?
minusing again; this is highly dependent upon system configuration -- it will be slower for some people and faster for others (e.g. on 3 systems that i've tried here, trunk was faster than 2.0).
Flags: blocking1.9? → blocking1.9-
I really don't think this is not important. Even if it was system dependent, I guess that most of the people running Firefox are using Windows XP, as it is the most commonly used OS in present... And this is a problem. If this was a problem of some exotic kind of BSD, or I don't know what, that could be considered to be a minor issue. But not when it's happening on XP. I will check that on Windows Vista, but I expect to get the same result. If a dirty hack was used in final Firefox 2 to correct this, there must be a way to fix this.
I agree. It's very important that this doesn't regress on the biggest platform, which is windows. Tested on my windows Vista machine: 9891ms for current trunk 5896ms for branch Using a GeForce 6100 nForce 405, 32-bits color depth. On my windows XP machine: 10125ms for current trunk 4531ms for branch Using a GeForce Go 7300, 32-bits color depth I think these are quite common configurations. And it is slower for me.
Similar report in Bug 282600
When using Linux and Metacity window manager, that testcase is not a problem (4616s). When using Compiz, it is a big problem (12921ms).
Currently I don't see any slow down. On the contrary, tests done with Fx3 are 20% faster than Fx2 ones. Tested with blank profiles. Can you retest this bug? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008060906 Minefield/3.0pre
Nothing, ignore my previous comment. See instead Bug 372039 Comment #22
I am also getting this bug in Firefox 3 RC2. System: Windows XP SP3 ATI Radeon 9200SE, 32-bits, 1280x1024 This bug seems to be quite prevalent. Here are a few (probably) related/duplicate bugs: bug 437691, bug 424047, bug 382791 Any chance of getting this fixed for the final release?
This bug depends on bug 374980, which isn't going to land on FX3.
Duplicate of this bug: 382791
Duplicate of this bug: 437691
Do you think Bug 429351 is a DUPLICATE of this bug?
Duplicate of this bug: 429351
What's the actual perf hit between the two builds given in the regression range?
See comment 7, current trunk builds are at least 2 times as slow as branch builds, probably even worse.
OK. Do we know what specific system configurations cause the 2x slowdown? Thinking of vlad's comment 5 above.
As I said in Bug 372039 Comment 22, it depends also from the screen resolution.
This is with a NVidia GeForce 7300 video card. I suspect this slowdown occurs with all NVidia video cards. I think this is very common.
I'm also getting it with an ATI card (see above).
I have an Intel Q9450(4x 2.66ghz Cores) and an Nvidia 8800 GT and I see this problem on various sites that have fixed backgrounds.
I don't think it depends from graphic card. I have an ATI Radeon X1200 chip integrated in the motherboard. I repeat, IMO it depends from resolution. Try to run the testcases of this bug and of Bug 372039 with Fx2 and with Fx3 at different resolutions. I didn't see differences running this testcase with Fx2: https://bugzilla.mozilla.org/attachment.cgi?id=212976 but with Fx3 the slowdown at higher resolutions is relevant.
fwiw,i done some test runs of the testcase here using different resolution, using intel gma 3100 integrated video card, Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008062318 Minefield/3.1a1pre ID:2008062318 800x600 time this took is: 4275ms time this took is: 4179ms time this took is: 4171ms 1024x768 time this took is: 4295ms time this took is: 4353ms time this took is: 4296ms 1152x864 time this took is: 8347ms time this took is: 8382ms time this took is: 8357ms 1280x600 time this took is: 7594ms time this took is: 7616ms time this took is: 7572ms 1280x720 time this took is: 8280ms time this took is: 8261ms time this took is: 8271ms 1280x768 time this took is: 8490ms time this took is: 8418ms time this took is: 8340ms 1280x960 time this took is: 8663ms time this took is: 8549ms time this took is: 8677ms 1280x1024 time this took is: 8618ms time this took is: 8646ms time this took is: 8664ms 1440x900 time this took is: 8765ms time this took is: 8629ms time this took is: 8627ms
Those are my measurements. I've tested it with Firefox 188.8.131.52 and with Firefox 3.1a1pre 2008062204, at 800x600 @100Hz and at 1280x1024 @60Hz. I've done 10 measures, here I report only the mean value. I've done some tests also at 800x600 @60Hz and the values seems to be equal, so frequency is not related. Fx2 Fx3 800x600 5170 4310 1280x1024 5155 9195 It's evident Firefox 2 is more slow with low screen resolution, but its performance is _the same_ with all resolutions. On the contrary Firefox 3 performance degrades with higher resolution, as you can see also in previous comment. With a 1280x1024 resolution the elapsed time is _more than double_ of 800x600 time. A strange fact is with this resolution the Cairo performance is better (~17%).
I just tested with a 800x600 resolution. My testcase isn't really suited for that resolution, because the scrolling area seems to be too short. Also, because of less screen estate, I guess the cpu usage can remain under 100%, but I think it would be still quite easy to reproduce the regression for 800x600 resolutions. Timers are improved in Fx3, so when just timers are measured, Fx3 might seem quicker.
You are very right. I've rewritten the testcase, so it works with 800x600 well and it's not dependent from setTimeout improvements. My new measurements are much more impressive.... Fx2 Fx3 800x600 1390 1687 1280x1024 2037 33162 This time I've done only one run (because Fx3 at high resolutions is _too_ slow) at 60Hz with both resolutions.
Well, I noticed something strange: there's a loss of performance even if there's no background image! Furthermore I noticed there's a regression of scrolling performance of ~20% comparing Fx3 trunk build 2008-02-06-14 and 2008-02-07-04. These are the bugs fixed in regression date range: http://preview.tinyurl.com/63huga/ Bug 412314 seems 'suspect' to me.
Ok, I created another testcase. The main difference is simply the background image, that has a very big size. You can notice with this huge image the scrolling is slowed down in particular when the image finishes and must be repainted. Does this bug depend on Bug 374980?
Lucas, do those testcases have the same regression range as mentioned in comment 0? If they don't they are likely to be different issues and you should file new bugs for them.
Testcase in comment 31 seems to be really another issue. Anyway the new testcase in comment 32 is virtually the same of old ones. It has only a bigger image and a better measuring method.
Assignee: nobody → vladimir
Priority: -- → P2
I am using "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b1pre) Gecko/20080914020350 Minefield/3.1b1pre" - the testcase works fine for me now. Testcase #1 - 3981 ms In Firefox 3.0: Testcase #1 - 22432 ms I am running on Linux. There are three performance issues with Firefox right now: - scrolling with fixed elements on a website - zooming on Linux (it looks like on every zoom it loads the fonts again and again, until the font is cached - that's why after resizing the website 3-4 times it starts working properly) - Interface is blocked when FF is loading huge page But, this bug seems to be fixed for me in the newest trunk. PS. The testcase was done on 1680x1050 - and it just cannot be smoother IMHO.
The testcase is still slow for me, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913031911 Minefield/3.1b1pre In the order of 10 seconds, still. The first performance issue, mentioned in comment 36, is already covered by a different bug. I don't know about the other ones. If there aren't bugs filed for those, please file those. In general, don't try I also think it is the cause of the slowness of this page, by the way: http://whoisfollowingme.com/cogito_ergo_sum.php
Flags: blocking1.9.2? → blocking1.9.2-
Jeff, will you run this on your Windows 7 machine and tell us the results? I think this is mostly fixed.
Assignee: vladimir → jmuizelaar
Using the latest hourlies with retained layers this test takes 48ms. Firefox 3.6 takes 528ms. That is a massive improvement. Chrome however takes 6ms. This can probably be closed, should another bug be opened for the remaining performance difference?
Ryan: I think so, yes (gfx gents: reopen if you dissent)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified. The two testcases don't show any measurable difference anymore, and scrolling on the mentioned pages is very fast, no slowness at all perceived. It also seems that the testcases don't really test scrolling performance on Chrome, as the scrollBy is not directly executed on Chrome.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.