Open Bug 693105 Opened 13 years ago Updated 2 years ago

High CPU usage by auto slideshow combining cropped scrolling/resizing/opacity triggering reflows

Categories

(Core :: Web Painting, defect)

defect

Tracking

()

People

(Reporter: judavecht, Unassigned)

References

Details

(Keywords: perf)

Attachments

(8 files)

User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.202 Safari/535.1

Steps to reproduce:

I open page on my site with an image slide show (Joomgallery), eg http://www.bblopers.nl/hoe-trainen-wij
containing this script:
http://www.bblopers.nl/modules/mod_joomimg/assets/slideshow.js


Actual results:

 CPU use goes op to 50% or more (Firefox 7.0.1, winXP), and the pictures are moving slowly.


Expected results:

CPU use should have stayed down and moving pictures should be quickly as eg Chrome and even IE do.
The problem is not new, I silently hoped that FF 7.0.1 got rid of the problem but it is still there.
Seeing className used in the script it might be related to bug 641094
The given script seems to be from 2007 and the creators of it updated it to
http://smoothgallery.jondesign.net/getting-started/
Not sure if they better adjusted for browser shortcomings in that regard - Firefox has many open tracking bugs about DHTML/DOM performance:
bug 21762, bug 118933, bug 143097, bug 203448, bug 213943, bug 558145, bug 622298.
(works even worse in IE8 for me)
Keywords: perf
Can't find an exact dupe, so marking as new. I can see CSS3 animations/transitions being capable of this as an alternative to javascript, and I'll revisit this when I have time to create examples for performance comparison.
Status: UNCONFIRMED → NEW
Component: General → DOM
Ever confirmed: true
Keywords: perf
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → general
Hardware: x86 → All
Summary: Script on my website is slow in Firefox but not in other browsers → High CPU usage by javascript auto slideshow combining cropped scrolling/resizing/opacity
Version: 7 Branch → Trunk
Keywords: perf
This has nothing to do with DOM.

Or more precisely, 4% of the time on this testcase is spent doing anything with the DOM, inline styles, etc.  Another maybe 3% is spent on restyling and relayout.

80% is spent on painting.

And of the painting, only 1/8 is spent under nsDisplayImage::Paint; the rest is painting text, backgrounds, etc, etc.

So I'm guessing that we're repainting the whole page for some reason.  Probably because we end up reflowing and our invalidation stuff is all broken?
Component: DOM → Layout: View Rendering
Depends on: dlbi
QA Contact: general → layout.view-rendering
(In reply to Boris Zbarsky (:bz) from comment #4)
> So I'm guessing that we're repainting the whole page for some reason. 
> Probably because we end up reflowing and our invalidation stuff is all
> broken?

Yes. The body of the article is float: left, the image is float:right, whatever we do to the image causes us to reflow it, and in nsBlockFrame::ReflowLine we get the inline case (http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBlockFrame.cpp#2533) and invalidate the whole line, which is at least the image and all of the body text.

If you control this page you could probably make a small change to avoid this particular bug.
Attached image Image 1 for test cases
Attached image Image 2 for test cases
Attached image Image 3 for test cases
Attached image Image 4 for test cases
Summary: High CPU usage by javascript auto slideshow combining cropped scrolling/resizing/opacity → High CPU usage by auto slideshow combining cropped scrolling/resizing/opacity triggering reflows
Clicking on the page heading lets you use Esc to toggle pausing of animations.
Attached image image 5 for test cases
Even without opacity and text overlay animation, this one still takes 100% of my cpu (note: I don't have hardware acceleration, old computer)
(In reply to Mardeg from comment #13)
> Created attachment 568892 [details]
> Testcase #3 - simpler CSS animation on a single image
Mozilla/5.0 (Windows NT 5.1; rv:13.0a1) Gecko/20120201 Firefox/13.0a1
With nglayout.debug.paint_flashing set to true I see the <figure> area flashing every time the image moves on hover. I think this testcase may be more to do with bug 157681.
Is this bug related to or a dupe of bug 546362?
See Also: → 905432
Component: Layout: View Rendering → Layout: Web Painting
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: