Closed
Bug 361754
Opened 18 years ago
Closed 14 years ago
Bad scrolling performance with Cairo builds using large background-image
Categories
(Core :: Graphics, defect, P2)
Tracking
()
VERIFIED
FIXED
People
(Reporter: martijn.martijn, Assigned: jrmuizel)
References
()
Details
(Keywords: perf, regression, testcase)
Attachments
(3 files, 4 obsolete files)
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.
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Updated•18 years ago
|
Keywords: regression
Comment 2•18 years ago
|
||
testcase next
Comment 3•18 years ago
|
||
Reporter | ||
Updated•18 years ago
|
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Reporter | ||
Comment 4•18 years ago
|
||
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-
Comment 6•17 years ago
|
||
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.
Reporter | ||
Comment 7•17 years ago
|
||
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.
Updated•17 years ago
|
Flags: blocking1.9-
Reporter | ||
Updated•17 years ago
|
Severity: normal → major
Comment 8•17 years ago
|
||
Similar report in Bug 282600
Updated•17 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Reporter | ||
Updated•16 years ago
|
Flags: wanted1.9.1?
Flags: blocking1.9.1?
When using Linux and Metacity window manager, that testcase is not a problem (4616s).
When using Compiz, it is a big problem (12921ms).
Comment 10•16 years ago
|
||
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
Comment 11•16 years ago
|
||
Nothing, ignore my previous comment. See instead Bug 372039 Comment #22
Comment 12•16 years ago
|
||
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?
Comment 13•16 years ago
|
||
This bug depends on bug 374980, which isn't going to land on FX3.
Comment 17•16 years ago
|
||
Do you think Bug 429351 is a DUPLICATE of this bug?
Comment 19•16 years ago
|
||
What's the actual perf hit between the two builds given in the regression range?
Reporter | ||
Comment 20•16 years ago
|
||
See comment 7, current trunk builds are at least 2 times as slow as branch builds, probably even worse.
Comment 21•16 years ago
|
||
OK. Do we know what specific system configurations cause the 2x slowdown? Thinking of vlad's comment 5 above.
Comment 22•16 years ago
|
||
As I said in Bug 372039 Comment 22, it depends also from the screen resolution.
Reporter | ||
Comment 23•16 years ago
|
||
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.
Comment 24•16 years ago
|
||
I'm also getting it with an ATI card (see above).
Comment 25•16 years ago
|
||
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.
Comment 26•16 years ago
|
||
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.
Comment 27•16 years ago
|
||
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
Comment 28•16 years ago
|
||
Those are my measurements. I've tested it with Firefox 2.0.0.14 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%).
Reporter | ||
Comment 29•16 years ago
|
||
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.
Comment 30•16 years ago
|
||
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.
Attachment #246464 -
Attachment is obsolete: true
Attachment #246466 -
Attachment is obsolete: true
Comment 31•16 years ago
|
||
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.
Comment 32•16 years ago
|
||
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?
Attachment #246465 -
Attachment is obsolete: true
Attachment #326538 -
Attachment is obsolete: true
Reporter | ||
Comment 33•16 years ago
|
||
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.
Comment 34•16 years ago
|
||
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
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P2
Comment 36•16 years ago
|
||
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.
Reporter | ||
Comment 37•16 years ago
|
||
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
Reporter | ||
Updated•16 years ago
|
Flags: blocking1.9.2?
Updated•15 years ago
|
Flags: blocking1.9.2? → blocking1.9.2-
Reporter | ||
Updated•15 years ago
|
blocking2.0: --- → ?
Flags: wanted1.9.2?
Comment 38•15 years ago
|
||
Jeff, will you run this on your Windows 7 machine and tell us the results? I think this is mostly fixed.
Assignee: vladimir → jmuizelaar
Updated•15 years ago
|
Comment 39•14 years ago
|
||
At most web pages I have no problems with scrolling, under ANY conditions. I was a bit blurry eyed this morning, and so I "increased the text size" (ie, magnified the web page) via the Ctrl-+ hot key. I noticed that vertical scrolling was VERY slow on this web page http://www.maximumpc.com/article/howtos/sync_your_music_library_across_multiple_computers where I just ran some tests (see below).
My Environment: I have a Dell 9300 laptop with an nVidia Geforce Go 6800 video card, LCD resolution of 1920 x 1200, Windows XP SP3, and Firefox 3.6.6. Due to the high resolution of the LCD (which can make text tiny) I have FireFox configured with Content -> Default Font: Arial Size 17 -> Advanced: Minimum font size: 17, and Unchecked: "Allow pages to choose their own fonts". I ran "Test Set 1" with those options, and for "Test Set 2", I set Minimum font size to "None". The tests show the number of seconds to scroll vertically from the top of the web page to the bottom using the down arrow key, for four different environment combinations where I use Ctrl-0 (zero) to set the page "magnification" to default, Ctrl-+ three times to increase page magnification three times, Firefox drop down menu: View -> Page Style -> "No Style" or "Basic Page Style" (the default). I did not change the "Allow pages to choose their own fonts" setting because this page does not override the Firefox default font, so it is irrelevant.
== Test Set 1 (Minimum font size: 17)
Sec Environment
--- -----------
25 Ctrl-0 Basic Page Style
18 Ctrl-0 No Page Style
89 Ctrl-+(*3) Basic Page Style
18 Ctrl-+(*3) No Page Style
== Test Set 2 (Minimum font size: None)
Sec Environment
--- -----------
18 Ctrl-0 Basic Page Style
18 Ctrl-0 No Page Style
66 Ctrl-+(*3) Basic Page Style
18 Ctrl-+(*3) No Page Style
Then I decided to run Test Set 1 with page images turned off:
== Test Set 3 (Minimum font size: 17), Images turned Off (also reduces total web page height)
Sec Environment
--- -----------
18 Ctrl-0 Basic Page Style
14 Ctrl-0 No Page Style
69 Ctrl-+(*3) Basic Page Style
14 Ctrl-+(*3) No Page Style
Next, I decided to reload the page after turning Images off:
== Test Set 4 (Minimum font size: 17), Images turned Off (and then reload the page)
Sec Environment
--- -----------
9 Ctrl-0 Basic Page Style
11 Ctrl-0 No Page Style
9 Ctrl-+(*3) Basic Page Style
12 Ctrl-+(*3) No Page Style
Next, I disabled all my Firefox extensions and ran some tests, all with Minimum font size 17:
== Test Set 5 Images turned Off then reload page (note: page now has advertisements as well)
Sec Environment
--- -----------
10 Ctrl-0 Basic Page Style
14 Ctrl-0 No Page Style
10 Ctrl-+(*3) Basic Page Style
14 Ctrl-+(*3) No Page Style
== Test Set 6 Images turned On then reload page (note: page now has advertisements as well)
Sec Environment
--- -----------
25 Ctrl-0 Basic Page Style
19 Ctrl-0 No Page Style
102 Ctrl-+(*3) Basic Page Style
19 Ctrl-+(*3) No Page Style
Note: I also tried disabling JavaScript and running some of the tests, but it made no difference in test times.
=== POTENTIAL CONCLUSIONS:
None of my 21 Firefox extensions are causing the problem. Of my browsing habits, MOST web pages do NOT exhibit this problem. It seems that when SOME web pages are "magnified" either by a minimum font size or by manually forcing a temporary magnification via the Ctrl-+ hotkey, AND images are turned on (which the vast majority of web users do), AND with BASIC PAGE STYLE turned on (which the vast majority of web users do) that "vertical scrolling" slows down exponentially in relation to the level of increased magnification (ie, see Test Set 5 vs Test Set 6). I seem to recall in older versions of Firefox that when a user magnified the screen, that only the TEXT was magnified, but not the IMAGES. At some version update, Firefox also started to magnify the images, which seems like a good idea since someone with "blurry morning eyes" wants to see everything without squinting. However, if the method of magnifying the images can not be made to do so without hugely impacting scrolling speeds (that would be the best solution), then perhaps the user should be able to toggle that "increased image size during magnification" feature on/off.
Reporter | ||
Comment 40•14 years ago
|
||
I guess bug 564991 might also improve things here.
Depends on: 564991
Comment 41•14 years ago
|
||
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: 14 years ago
Resolution: --- → FIXED
Comment 43•14 years ago
|
||
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
Comment 72•2 years ago
|
||
We are thankful to you to provide this much information here on this page. Know more: https://playonlinesattamatka.com/
Comment 73•2 years ago
|
||
American Hydrocarbon is a world class custom engine bay and interior show car design company with show winning cars in 28 countries around the globe. We are featured in Vette magazine, Corvette magazine and on Corvette Web.Know more:
https://americanhydrocarbon.com/
You need to log in
before you can comment on or make changes to this bug.
Description
•