438911 - moz-border-radius == 100% CPU load when scrolling

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Matt Jones]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0

Loading a page with several nested rounded tables with background images will completely peg the CPU at 100% when scrolling.  This is a regression from FF2 which does not exhibit any such performance issues, it does render the rounded corners far uglier.

Reproducible: Always

Steps to Reproduce:
1. Open the provided link: http://roberts.plumgroup.com/moz-border-radius/index.html using FF3
2. Scroll around the page
3. Watch the CPU usage skyrocket and the scrolling lag
Actual Results:  
The CPU is pegged at 100% and continues until the scrolling page catches up.

Expected Results:  
Minimal CPU usage and nice smooth scrolling.

I have confirmed this on both Linux and WinXP with the latest release candidate of FF3.  This occurs regardless of whether smooth scrolling is enabled or not, though it is even more pronounced with smooth scrolling.

Comment 1

[Matt Jones]

Confirmed on the latest trunk release

Comment 2

[cmtalbert]

I can't recreate this issue. Tried it on Mac, Vista, and Windows XP, and Ubuntu 8.04:

Are you sure it's this page that's causing it?  Did you try it without extensions installed? If I scroll up and down fast enough I can cause a spike to 100% CPU usage, but I can't get that with normal scrolling or even with fast scrolling on any of these platforms.  And the scrolling is always responsive.

Vista: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081020 Minefield/3.1b2pre
Mac: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b2pre) Gecko/20081020 Minefield/3.1b2pre
XP:  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081020 Minefield/3.1b2pre

On Ubunutu 8.04, I did not see the 100% CPU spike, but I did see the scrolling become laggy.  The page would continue to execute my scrolling commands after I'd stopped scrolling the mouse.  But that's only part of what you're describing.  And I only got this to happen if I scrolled it quickly up and down many times.
Ubuntu: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081020 Minefield/3.1b2pre

Comment 3

[Matt Jones]

Your description on Ubuntu sounds exactly like my experience on both windows xp and fedora 9.  I am am running a dual core processor I am only seeing one of my CPUs spike to 100%, but obviously the process has hit the limit if it is becoming laggy on a 2.4GHz dual core processor.

You mention scrolling up and down many times, this obviously isn't a standard use case, but you have to acknowledge that you can't recreate that behavior with any other site regardless of how fast you scroll up and down.  Clearly something is killing performance in the rounded border code.  Also, this seems highly dependent on the resolution of the window.  On a higher resolution window (1280x1024) this issue becomes even more pronounced.

On OS X performance is better and I am not seeing lag, but I can see a considerably higher CPU load (>70%) just by scrolling by holding the down arrow compared to the load of any other site I can find (<20%).

I do not see any of these issues with other browsers that support border radius styling or with Firefox 2.0.  If this feature creates this much load (and potential lag) on a dual core 2.4GHz processor how can we actually consider using this feature on a system with only the recommended requirements of 500MHz.

I recognize that this is not a show stopper bug, but I do consider this bug to make rounded corners a non-starter if you have to consider even remotely slower systems particularly windows or linux.

Comment 4

[Carlos Alén Silva]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 GTB5

I can confirm CPU spikes and scroll lag scrolling normally + smooth scrolling disabled on Windows XP SP 3. Scrolling slowly sufficed to reproduce the bug.

Steps to Reproduce:
1. Open the provided link:
http://roberts.plumgroup.com/moz-border-radius/index.html using Fx 3.5.3
2. Scroll SLOWLY around the page
3. Watch the CPU usage skyrocket and the scrolling lag

Comment 5

[cmtalbert]

Tried again on both windows and mac, and I still can't repo this :(  Did you try this with no extensions enabled? (though that seems doubtful that an extension related problem would only affect pages with moz-border-radius if that were the case).  

Hmm not sure what to think on this one.  You guys can reproduce this at will, but I still can't get it to happen.  How slowly is slowly?  Perhaps this is timing related?  What was happening in your background tabs?

Comment 6

[Carlos Alén Silva]

Attachment: 99% CPU Fx 3.5.3, Safe Mode, no tabs

Test URL in Fx 3.5.3, Safe Mode, no tabs, yields 99% CPU firefox.exe usage when scrolled wildly up and down. Wildly = as fast as I could possibly scroll the mouse wheel.

When scrolling at more moderate speed, I still managed to get ~50% CPU usage.

Comment 7

[Carlos Alén Silva]

(In reply to comment #5)

> Hmm not sure what to think on this one.  You guys can reproduce this at will,
> but I still can't get it to happen.  How slowly is slowly?  Perhaps this is
> timing related?  What was happening in your background tabs?

When I stressed 'slowly' I was referring to your last paragraph in  comment #2: "And I only got this to happen if I scrolled it quickly up and down many times."

You can take this slowly to mean "one mouse wheel 'tick' per second". But, in any case, I can definitely reproduce the bug, even on safe mode with no tabs. CPU usage gets worse for me, the more rapidly I scroll up and down, but just scrolling "one mouse wheel 'tick' per second" all the way down, and then back up, gets me a nice CPU boost around 50%.

Comment 8

[Carlos Alén Silva]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090925 Shiretoko/3.5.4pre GTB5

Fx 3.5.4pre yields same results as in Comment #6: 99% CPU usage when scrolling wildly. ~50% when scrolling at moderate speeds.

Comment 9

[Matt Jones]

Having submitted the original bug I should probably provide the additional insight I've gained by testing this further on the various computers and operating systems I have access to.  The bug was originally submitted because under what I would consider "normal" scrolling (a few mousewheel clicks) would cause visual stuttering.  I have found that the user experience varies greatly (ranging from badly stuttering to smooth but 100% CPU usage on a single core) depending on the graphics chipset and driver version being used.

Oddly the worst performers were higher end nvidia cards (8000 and 9000 series) on windows and linux with the generation of drivers available when this bug was submitted (177.X series).  While the best performer was my intel gma x3100 macbook on mac os x, windows or linux.  It seems like a 2D drawing optimization was either not implemented or poorly implemented in these nvidia drivers.  More recent drivers have definitely improved the situation on both linux and windows.

Given that updated drivers do seem to correct the stuttering issue I'm sure it will be tempting to close this bug as "fixed".  However, it does seem strange that having nested rounded corners should cause such a massive 100% CPU spike especially when compared to CPU usage when there are no rounded corners.

Comment 10

[Tobias B.]

yesterday i read some posting in the mozilla forum about bad performance in firefox and css3 properties (-moz-border-radius and also -moz-box-shadow):
http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=638706&forumId=1

the posting describes more the bad performance on hover effects, but this is the same problem. i could figure out that performance is only poor on hover effects which causes a reflow. see my comment (the last one on the page) for more information.

i'm not sure if scrolling does cause a reflow / repaint, but i guess it does. if that's the case, i would say that usage of some css3 properties like -moz-border-radius and -moz-box-shadow in combination with a browser reflow / repaint is the reason for the bad performance.
since the problem is not present in firefox 2 and in firefox 3 there was a big change how the browser handles reflows/repaints (http://articles.sitepoint.com/article/firefox-3-whats-new-whats-hot/4) this would make a lot of sense.

Comment 11

[Simon Jonsson]

I am one of those having huge problems with the bad performance from -moz-border-radius and -moz-box-shadow. I have also written in http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=638706&forumId=1 and left feedback for firefox 4 beta about it.

I have made a test page so that others hopefully can see the problem. http://simonjonsson.com/dev/css3-performance-test/

Everyone may not have the problem but I do, just like many others in the above mentioned thread. My PC has a core 2 duo E6600, 4GB RAM and an ati x1900xt, ie. not that old.

I would have to agree with Tobias B on "i would say that usage of some css3 properties like
-moz-border-radius and -moz-box-shadow in combination with a browser reflow /
repaint is the reason for the bad performance.
"

Comment 12

[Giorgio]

on win7 with quad6600 and ati48701gb i've a lot of performance problem when i use border-radius

in one page i've some test effects (shadows, transparency rgba(), 32bit pngs)

they slows down scrolling but it is not so bad,

but when i add border-radius on these boxes page scrolling is TOTALLY unusable

Comment 13

[Spiros Ioannou]

see also https://bugzilla.mozilla.org/show_bug.cgi?id=611963

Comment 14

[Robin Whittleton]

The original testcase has disappeared from the web. I tried the testcase in comment #11 (http://simonjonsson.com/dev/css3-performance-test/) and could only get Firefox 50 (today’s nightly) up to 45% CPU on my 2012 Macbook Air with no loss of performance. WONTFIX?

Comment 15

[Gregory Pappas [:gregp]]

Unable to reproduce in recent versions, all test cases perform well.