Closed Bug 500410 Opened 15 years ago Closed 3 years ago

javascript "animation" (cross browser marquee II on dynamicdrive.com) brings FF to its knees (CPU performance) but works fine in IE

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: cr, Unassigned)

References

(
URL
)

Details

Attachments

(4 files)

Reference comparison <marquee> example.
1.38 KB, text/html
Details
Minimal testcase of 30ms example
44.07 KB, text/html
Details
Jobs file for Alternate Scroll testcase.
33.60 KB, text/html
Details
Minimal testcase of 30ms Alternate scroll
9.95 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 GTB5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 GTB5 (.NET CLR 3.5.30729)

Our website is designed using a javascript animation. The javascript works fine in IE, but when run in FF it brings the CPU usage WAY UP !!

Even if you run the script in isolation, from its home page on the Dynamic Drive website, you see this happening.

1) Script Title:
Cross Browser marquee II

2) Script URL (on DD):
http://www.dynamicdrive.com/dynamicindex2/cmarquee2.htm

3) Describe problem:

When I view the marquee in IE it works just fine but when I view it in firefox it degrades the performance of my PC.

Using TaskManager > Processes I can see that firefox.exe is now taking approx on average 30-35% of the CPU time.

When I move the mouse over the marquee to pause the marquee scrolling, after a second or two the CPU %age for firefox drops to 0. Then if I mouse away and scrolling starts again, the CPU usage rises again to the previous level.

I on XP Home SP3. 1.35GHz AMD Athlon CPU and 448MB RAM.

(NB I first discovered this problem as our website was coded by a webdesigner a few years ago using a version of this marquee, and when we moved to firefox last month I noticed CPU usage went to nearly 90% when the marquee scrolled, and everything else was totally killed. See www.altmore.co.uk. I got a shock when I found that firefox was struggling even with the source javascript on Dynamic Drive too, though not as much as with our site - maybe the amount of text were putting through it might be a factor ?

PS this could explain the problems ppl have with firefox viewing flash on the same page as the marquee, as flash is also processor hungry)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

on my work PC (which is slightly higher spec than my home PC) I can reproduce this also, but at average of approx 25% of CPU usage - which is still way above what it should be.... (drops to 0-2% when scrolling paused)

spec = XP Pro SP3
2.53GHz Celeron CPU, 1.99GB of RAM



Reproducible: Always

Steps to Reproduce:
1. go to the website above (in URL field)
2.
3.
Actual Results:  
on my work PC (which is slightly higher spec than my home PC) I can reproduce this also, but at average of approx 25% of CPU usage - which is still way above what it should be.... (drops to 0-2% when scrolling paused)

Expected Results:  
CPU usage should not rise more than 1 or 2%

this may possibly be related to or even the same bug as 

https://bugzilla.mozilla.org/show_bug.cgi?id=442797

I couldn't tell from info provided
Checked on Mozilla/5.0 (X11; U; Linux i686; nl; rv:1.9.1) Gecko/20090618 Remi/fc11 Firefox/3.5. 

Does not occur in this version. That's positive.
see also bug report on dynamic drive website

http://www.dynamicdrive.com/forums/showthread.php?p=199691#post199691
(In reply to comment #2)
> see also bug report on dynamic drive website
> 
> http://www.dynamicdrive.com/forums/showthread.php?p=199691#post199691

..where a few others have been able to reproduce it...
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090625 Minefield/3.6a1pre (.NET CLR 3.5.21022)

Worked fine for me; have you tried safe mode? 

http://support.mozilla.com/en-US/kb/Safe+Mode
@2pawnder

yes, reproduced it in safe mode (& thanks for safe mode instructions)

both machines I'm reproducing this on use AMD chips - could that be significant ?
At this line in the code:

setTimeout('lefttime=setInterval("scrollmarquee()",30)', delayb4scroll)

what happens if you change 30 to 90?
The reason I ask this because I saw the following info at https://developer.mozilla.org/en/HTML/Element/marquee

"scrolldelay: Sets the interval between each scroll movement in milliseconds. The default value is 85. Note that any value smaller than 60 is ignored and the value 60 is used instead, unless truespeed is specified."

The fact this needs truespeed to override the minimum allowed interval might point to it being a bit CPU intensive. For reference comparison I've attached an example using <marquee> with speed matching the DD example speed/interval/text.
@2pawnder

yes, reproduced it in safe mode (& thanks for safe mode instructions)

both machines I'm reproducing this on use AMD chips - could that be significant
?
I'm sorry; I'm not really sure. Sorry about this issue that you're having. Does the CPU still work hard in the attachment Mardeg posted?
@2pawnder

yes, reproduced it in safe mode (& thanks for safe mode instructions)

both machines I'm reproducing this on use AMD chips - could that be significant
?
@2pawnder - the CPU worked about 10% harder in that page Mardeg posted (from ~15% to ~25%). Obviously this is slightly different as it uses the HTML tag "marquee" rather than javascript (but I'm assuming these are related behind the scenes).

In our website, altmore.co.uk, the CPU was up near 100% using the javascript (with 30ms as the delay param). Bby switching to 500ms I got CPU usage down to 20%. Thats what you'll see now, as I've made the change on the live site. The marquee scrolls VERY slowly but I'd rather have that than the site unusable to a quarter of the audience (FF users).

Its a workaround for now, but ideally I'd think the FF javascript VM/engine needs looked at. 

This code does not trouble IE in the slightest !
The site used about 5% of my CPU. Sometimes it peaked at about 15%. Although it isn't as much as you are using, I think they might still be an issue. Can someone else verify?
Status: UNCONFIRMED → NEW
Ever confirmed: true
@2pawnder - the CPU worked about 10% harder in that page Mardeg posted (from ~15% to ~25%). Obviously this is slightly different as it uses the HTML tag "marquee" rather than javascript (but I'm assuming these are related behind the scenes).

In our website, altmore.co.uk, the CPU was up near 100% using the javascript (with 30ms as the delay param). Bby switching to 500ms I got CPU usage down to 20%. Thats what you'll see now, as I've made the change on the live site. The marquee scrolls VERY slowly but I'd rather have that than the site unusable to a quarter of the audience (FF users).

Its a workaround for now, but ideally I'd think the FF javascript VM/engine needs looked at. 

This code does not trouble IE in the slightest !
Status: NEW → UNCONFIRMED
@all 

sorry for multiposting - getting the hang of this interface now.
Is there a way to delete duplicate posts?
@all 

sorry for multiposting - getting the hang of this interface now.
Is there a way to delete duplicate posts?
..so much for getting the hang of this interface...
I keep getting warned about mid-air collisions, even when no-one else seems to be editing. If I ignore them, I don't seem to create duplicate posts. 

Sorry everyone
BACK TO BUSINESS:

@2pawnder

Thanks for testing this. You probably tested the site after I'd amended it to use a much bigger delay of 500ms, which reduced the CPU usage significantly.

I have now set up 3x comparisons:

The live site (altmore.co.uk), has full data in the scroller and delay increased to 500ms. CPU usage ~ 20% (swinging up and down by 5-10% either side). Increasing the delay from 30ms to 500ms makes the scroller very slow, which is not ideal, but at least FF doesn't freeze so its a fudge for now.

The test site (altmore.co.uk/.test), is a facsimile of the live site before I increased the delay. i.e. it has full data in the scroller, and delay set to 30ms. CPU usage is up near 100% for me on FF (but next to nothing on IE).

The third case (altmore.co.uk/.test/_index_reduced_content.html) I created, as the name suggests, to see if the amount of content being scrolled was significant. It is.
This case has vastly reduced content (3 jobs instead of >50), and still has the delay at 30ms. It causes CPU usage of ~25% (again it swings up and down, this time by as much as 10-15%)

If someone would be good enough to try out each of these and report back, that would be great. I will post here if I change any of these configurations.
This takes my 2.2Ghz CPU up to a constant 99%
This is just a separate file to be used by another testcase
This one has my CPU between 3% and 24% hovering mostly at 12%
The reason I think the 1st testcase takes the CPU to 99%, and also why I don't think it is the ideal method to use for a scroller, is because it is reaching into the DOM to change actual CSS positions of the element - something that is triggering Firefox to refresh the DOM tree of the whole page in anticipation of having to move things out of the way. DOM traversal speed is a definite area for improvement in Firefox, and this might get duped or marked as dependant on bugs targeting that.
I tested the Alternate scroll testcase and found it to also work fine in IE8, Chrome 2, Safari 4, and Opera 10.
Just more testing, if it's useful:

Mardeg's testcases:
1. Hovering at 50%
2. About 25%
3. 5%-15%

Zorba's sites:
1. 10%-15%
2. 50%
3. Still 50%

I don't know if this is useful, but I hope it helps. This was on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090626 Minefield/3.6a1pre (.NET CLR 3.5.21022).
BACK TO BUSINESS:

@2pawnder

Thanks for testing this. You probably tested the site after I'd amended it to use a much bigger delay of 500ms, which reduced the CPU usage significantly.

I have now set up 3x comparisons:

The live site (altmore.co.uk), has full data in the scroller and delay increased to 500ms. CPU usage ~ 20% (swinging up and down by 5-10% either side). Increasing the delay from 30ms to 500ms makes the scroller very slow, which is not ideal, but at least FF doesn't freeze so its a fudge for now.

The test site (altmore.co.uk/.test), is a facsimile of the live site before I increased the delay. i.e. it has full data in the scroller, and delay set to 30ms. CPU usage is up near 100% for me on FF (but next to nothing on IE).

The third case (altmore.co.uk/.test/_index_reduced_content.html) I created, as the name suggests, to see if the amount of content being scrolled was significant. It is.
This case has vastly reduced content (3 jobs instead of >50), and still has the delay at 30ms. It causes CPU usage of ~25% (again it swings up and down, this time by as much as 10-15%)

If someone would be good enough to try out each of these and report back, that would be great. I will post here if I change any of these configurations.
zorba, can you do File -> Check for Updates, and use the 3.5 version you get to test https://bugzilla.mozilla.org/attachment.cgi?id=385508 please?
sorry, that's Help -> Check for Updates
from the menu
From http://weblogs.mozillazine.org/roc/archives/2009/07/progress.html it appears work to improve timing/painting content will go into the next major version after 3.5
Product: Firefox → Core
QA Contact: general → general
If I can ask for a favor.... can we please not do performance analysis without profiling?

On the "Minimal testcase of 30ms example", about 13% of the time is spent painting.  I doubt that compositor would help with this, especially since the page is using a 30ms interval and we'd want to be painting at closer to every 16ms with compositor.

What would help are:

1)  Not fully reflowing all the junk inside that abs pos div on style position
    change.  See also bug 157681.  This is 50% of total time.
2)  Not reresolving style on all said junk on every style position change.  See
    also bug 479655.  This is 20% of total time.

In general, please feel free to cc me on performance bugs...
Status: UNCONFIRMED → NEW
Depends on: 157681
Depends on: 479655
Depends on: 502288
The patch in bug 502288 drops reflow from 50% to 4% on this testcase, and drops CPU usage from 55% to 25% for me.

Bug 479655 is then the obvious thing that needs improving.
Depends on: 494117
OK, the patch in bug 479655 and the one in bug 494117 take the CPU usage from 22% to 15% or so.  

At this point, restyling is about 35% of total time, with about half of this the style struct getters called from CalcStyleDifference.  

Another 4% is reflow, and 6% is the actual script running.

35% is painting.  13% is OSX event processing gunk.

5% is appshell stuff.  That more or less sums things up.
Boris, can you please confirm if workaround alternate that uses scrollBy() at https://bugzilla.mozilla.org/attachment.cgi?id=385508 using the same measurements is still taking about half as much CPU on trunk compared to the above?
It's not.  Over here it's 13% CPU for the scrollBy testcase vs 16% for the other.
I have some possible ideas that might help the restyling part.  Painting, we'll see.
Depends on: 572200

Marking this as Resolved > Worksforme since this issue is no longer reproducible on the latest versions of Firefox Nightly 96.0a1 (2021-11-16), beta 95.0b8 or release 94.0.1 on Windows 10.
If anyone is still able to reproduce this issue please re-open the ticket or file a new one.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: