Closed Bug 657603 Opened 13 years ago Closed 2 years ago

slow scrolling with CSS gradients in this testcase

Categories

(Core :: General, defect)

x86_64
Windows 7
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: enfantsauvage, Unassigned)

References

()

Details

(Keywords: perf, Whiteboard: [ignore comment 11 through comment 41])

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Please visit http://leaverou.me/css3patterns/. The website is a gallery of CSS3 gradients and what can be achieved with them. Obliviously - it features heavy use of advanced CSS3 properties as well as JavaScript. Chrome runs quite smoothly on the site while Firefox chokes completely and lags. 
This difference is also noticeable when visiting any other site that uses CSS3 gradients to a bigger extend and also practically makes them unusable in development.

Reproducible: Always

Steps to Reproduce:
1. Visit http://leaverou.me/css3patterns/
2. Scroll the page or try to use any of the gradients featured there


Actual Results:  
Firefox is very slow and takes a long time to response, choking while scrolling

Expected Results:  
The gradients should have been rendered smoothly and there should be no difference in scrolling or speed than in normal usage.
Version: unspecified → 4.0 Branch
Confirmed that too slow scroll and high CPU usage on
http://hg.mozilla.org/mozilla-central/rev/6e4fb61ef475
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110516 Firefox/6.0a1 ID:20110516030622
Attached file reduced sample
It become 100 %CPU usage for a while.
*Scroll up and down.
*Switch tab.
*Resize browser.
*Switch window(blur focus).
Product: Firefox → Core
QA Contact: general → general
Version: 4.0 Branch → unspecified
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Version: unspecified → Trunk
Maybe related to other perf Bugs concerning Gradients like Bug 600042, Bug 632324 (what I reproduce without D2D too), Bug 644444 ...
And maybe a duplicate of the existing bug about this very same site?  ;)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
If this bug is specifically about http://leaverou.me/css3patterns/ then it is a dupe. But this bug seems to be talking about a more general problem. http://leaverou.me/css3patterns/ has a problem where we repaint the entire page when we scroll that is completely separate from slow gradients or other issues.
Well, fair.  I was taking this bug's expected vs actual results and steps to reproduce at face value.
So we'd either need a different testcase for this bug that exhibits the problem without making Firefox repaint the whole page on scroll or to wait until bug 655786 is fixed.
There's a testcase in comment 2 that doesn't involve scrolling, but _does_ force full-page repaints.
Oh sorry I missed that testcase. But that testcase does seem to involve scrolling?
I guess let's keep this open to cover that issue.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
i've noticed that this bug  is not only converned to  gradient backgrounds.
this web site.
http://ajl.co.ve/index.php
does not use gradient backgrounds but shadows and rounded corners and still makes CPU goes to the rook and Firefox irresponsively choppy when focusing on the page.

it does not seem to happen  in brand new computers just because they can ake the load.
Timothy (or Boris), could you correct the summary of this bug to reflect what it now covers (per comment 10)?
(In reply to Rafael Juarez from comment #11)
> i've noticed that this bug  is not only converned to  gradient backgrounds.
> this web site.
> http://ajl.co.ve/index.php
> does not use gradient backgrounds but shadows and rounded corners and still
> makes CPU goes to the rook and Firefox irresponsively choppy when focusing
> on the page.
> 
> it does not seem to happen  in brand new computers just because they can ake
> the load.

I see box-shadow with inset in http://ajl.co.ve/estilo.css so bug 509052 may be involved here.
maybe but 509052 bug involves scrolling.
this case, no need to scroll the page to see cpu going high.
Unless javascript is used to move the elements around triggering the same issue.
It seems either to let the CPU or GPU explode 
http://img651.imageshack.us/img651/8827/gpuexplosion.png
omg
Chromium 16 Nightly shows no issues with the GPU neither CPU hmm
Issues mentioned in this bug:
* slow scrolling at http://leaverou.me/css3patterns/ -> dupe of bug 655786
* 'reduced sample' attachment in this bug are this bug (but I'm a little confused about comment 8 saying that it doesn't involved scrolling)
* anything else mentioned here since then I can't follow, and are probably just confusing things.
Im using:Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0 ID:20111019081014 

Confirmed to show both issues: 
1.- related to http://leaverou.me/css3patterns/
2.- related to http://ajl.co.ve

more than a scroll problem, it's FF GPU usage exploding at the presence of certain css3 elements.

Tim:
this: http://img651.imageshack.us/img651/8827/gpuexplosion.png
explain a lot better than thousand words the issue about http://ajl.co.ve/index.php
Timothy yes that other site seems to be a new issue :( http://ajl.co.ve/index.php
though the outcome is the same (ultra unresponsive site feedback @ scrolling) only that this causes also the GPU (with D2D Azure enabled) to overflow :(
Opera 12 shows the best render Performance here
Summary: Firefox 4 is extremely slow and chokes on sites that have heavy CSS3 usage (like gradients) → slow scrolling with CSS gradients in this testcase
And IE9 actually that does excellent with hardware acceleration GPU only gets spiked on scrolling though it renders super smooth funny thing the site was showing it doesn't support Internet Explorer @ all but it is a much better experience with it :(
So true. what a frustration :-(
70% less images but 500% more resources commit.
still wondering if it's an overall issue about all css3 effects togheter or  it's one or two tricky tiny things.
Screencast: CPU usage changes as soon as page is focused.
http://screencast.com/t/QEFTvbnfHP
Folks, the purpose of a bug system is to track bugs towards being fixed.  One of the most important aspects of that is keeping only one issue per bug -- the issue being tracked.  If you raise other issues in a bug report, they'll just be ignored, and will furthermore make the original bug a lot harder to fix since it's harder to figure out what it is.

Please raise other issues in other bug reports.
David.
How can we  know this  is not the same bug?
choppy scroll could be due to high  CPU usage. 
no?

(In reply to David Baron [:dbaron] from comment #25)
If you aren't confident that it is the same bug, you should assume that it's not.
should i report a new bug then ?
Yes.  Report a new bug with a url, steps to reproduce, etc.  Thank you!
Yep Rafael also lets try to extract the item that is causing this especially also in context of D2D the GPU overflow without scrolling anything :)
another scrolling example that pushes resources to the max and almost brings firefox to it's knees (depending on the system) http://forums.bethsoft.com/index.php?/forum/91-rage-general-discussion/ is rendering this @ scrolling
Btw i was wrong Chromium 16 also has issues with Rafaels testcase same slow rendering only Opera 12 and IE9 don't show any issues on this one and on those so far catched ones only IE9 survives all of them with excellent Performance :/
Btw Rafael this site somehow immediately remembers me on the visual complexity of de.playstation.com only that yours is almost killing my system ;)
Rafael restart without Add-Ons i find massive issues with addons here it seems to cause severe problems i still have to identify those addons though :(
Ah no wait that just disables D2D so i have the pressure on the CPU now :(
Please Rafael open up that bug report when moving from GPU (D2D context) to CPU rendering http://img715.imageshack.us/img715/2784/1coreutilized.png
Though overall also IE9 has to fight with this but does quiet efficient :) it peaks @ 90W power consumption on a Sandy Bridge system depending on the state of the picture carousel.
CruNcher, please see comment 25.  You are making it harder to fix this bug by adding lots of comments not directly relevant to it.  Please file separate bugs on other testcases.  Please take general discussion to the mailing lists.  Feel free to contact me directly by e-mail for more information on where to do that.
moved my plea to bug 698294
sorry. what does D2D stands for ?
Whiteboard: [ignore comment 11 through comment 41]
The webpage sets up the z-index so that each pattern "button" is above the little twitter and facebook widgets that are in the top right corner. When a pattern button is no where near the social widgets it gets put into the same layer as the background, but when the pattern button moves close to the social widgets we have to move it from the background layer to its own layer because it needs to be drawn above the social widgets. Which means we need to redraw that area in both the old and new layer.

I think drawing gradients isn't particularly fast either, so that is part of the problem too.
maybe to give another example:

i tried to use one of those testcases on my site. css code is as follows:

body {
 padding: 0;
 margin: 0;

background:
  -moz-radial-gradient(black 15%, transparent 16%) 0 0,
  -moz-radial-gradient(black 15%, transparent 16%) 4px 4px,
  -moz-radial-gradient(rgba(255,255,255,.1) 15%, transparent 20%) 0 1px,
  -moz-radial-gradient(rgba(255,255,255,.1) 15%, transparent 20%) 4px 5px;

background-color:#282828;
background-size:8px 8px;
background-attachment: fixed; 	
}

works flawlessly with webkit browsers.

performance issues do not depend on OS in use. i received complaints from people using latest Ubuntu, OSX Snow Leopard and Lion (myself), Win XP and Windows 7. 

firefox is not only slow to scroll but also rendering takes a couple of seconds.
(In reply to Marcel Nowicki from comment #43)
> maybe to give another example
The above code in a html file
I hope this problem will get solved as it puts FF in really bad situation compared to Chrome, Opera or even IE9.

I created a table with about 15-20 rows. Each of them has :
"background: -moz-linear-gradient(center top , #F3F3F3 0%, #FFFFFF 50%, #F3F3F3 100%) repeat scroll 0 0 transparent;" style and with this FF goes really slow.
Remove it - all goes fine.
But chrome, opera, IE9 works smooth with that style.

Hope this info helps.
Has this been sorted? 

Rendering grids for backgrounds causes major lag issues, especially with any JS animation. Only FF does this.
FWIW, http://leaverou.me/css3patterns/ Perf is (nearly) on par with Chrome and Attachment 601086 [details] is WFM testing against http://hg.mozilla.org/integration/mozilla-inbound/rev/d1b79578a1bd (with Bug 823147 fixed).

Attachment 532963 [details] must have been fixed withing Firefox 14 <-> 17.
In my opinion it is not just the scrolling that saturates the CPU, but it happens just loading a page with extensive patters done with linear-gradient (obviously the scrolling worsen the problem). An extensive linear-gradient makes Firefox freeze on loading, in some cases for few seconds, in others for longer. To reproduce it, I created attachment 706784 [details] on bug 713992 that I suppose it's strictly related to this one.
Hi,

while testing a CSS background pattern I noticed some rendering issues and slow scrolling also. Here's the code I used:

http://dabblet.com/gist/5033295
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 13 votes.
:jstutte, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jstutte)

Hi Alice, do you happen to know if this is still an issue?

Flags: needinfo?(jstutte) → needinfo?(alice0775)

no longer reproduce the issue in Nightly107.0a1.

Status: REOPENED → RESOLVED
Closed: 13 years ago2 years ago
Flags: needinfo?(alice0775)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: