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)

Product:
Core
Component:
Graphics
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: martijn.martijn, Assigned: jrmuizel)

References

(
URL
)

Details

(Keywords: perf, regression, testcase)

Attachments

(3 files, 4 obsolete files)

Minimal Testcase #3: NO background!
1.74 KB, application/xhtml+xml
Details
Minimal testcase #4: heavy test
2.03 KB, application/xhtml+xml
Details
Assignment Help from PhD experts for brighter future and success. Promised top-notch quality assignments at a reasonable price.
683 bytes, text/plain
Details 
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.
Attached file testcase (obsolete) — 

    
  
Keywords: regression

    
    

    
  

      
      
      
      

        Attached image
          
        background for testcase (obsolete)
        — 
      

    


  
testcase next

    
    

    
  

      
      
      
      

        Attached file
          
        testcase incl background (obsolete)
        — 
      

    


  

    
  
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]

    
  
Blocks: 372039

    
    

    
  
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.

    
  
Flags: blocking1.9-

    
  
Keywords: perf

    
  
Severity: normal → major

    
    

    
  
Similar report in Bug 282600

    
  
Flags: wanted1.9+
Whiteboard: [wanted-1.9]

    
  
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).

    
    

    
  
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.

    
    

    
  
Is this bug a regression, or related to, Bug 382392?
Blocks: 368247

    
    

    
  
Do you think Bug 429351 is a DUPLICATE of this bug?

    
    

    
  
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 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%).

    
    

    
  
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.

    
  
Blocks: 441160

    
    

    
  

      
      
      
      

        Attached file
          
        Minimal Testcase #2 (obsolete)
        — 
      

    


  
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

    
  
No longer blocks: 441160

    
    

    
  


  
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?

        Attachment #246465 -
        Attachment is obsolete: true

        Attachment #326538 -
        Attachment is obsolete: true

    
    

    
  
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
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P2

    
    

    
  
Ok, let's hope bug 446376 fixes this.
Depends on: 446376

    
    

    
  
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?
Flags: blocking1.9.2? → blocking1.9.2-

    
  
blocking2.0: --- → ?
Flags: wanted1.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
blocking2.0: ? → -

          status2.0:
          --- → wanted

    
    

    
  
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.

    
    

    
  
I guess bug 564991 might also improve things here.
Depends on: 564991

    
    

    
  
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

    
    

    
  
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

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
  
We are thankful to you to provide this much information here on this page. Know more: https://playonlinesattamatka.com/



    
    

    
      
  

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: