442797 - Performance regression with scrolling marquee at www.buycomputers.co.za

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, after a while you get an alert that measures the time the marquee took to perform a scrolling operation.

With a branch build I get 3953ms as result.
With current trunk build, I get 20330ms as result.

A regression range would be helpful.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Regression range is
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1196822580&maxdate=1196824139
Caused by Bug 375304 ?

Comment 2

[Martijn Wargers (dead)]

Thanks, yeah, or caused by bug 406568, no idea. In any case, caused by the same person, so blaming is easy ;)

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Pretty slow on Mac too. I'll take this one.

Comment 4

[Tony]

Hi all,
This was brought to my attention and even though it used to work perfectly, I've moved onto using the much frowned upon <MARQUEE> tag, which works fine for our purposes. 

The original script was from Dynamic Drive http://www.dynamicdrive.com/dynamicindex2/cmarquee.htm which actually works fine in FF3, but for some reason wasn't fine with other javascript on the page. I actually rewrote the entire proc myself and had the same problem which left me with having multiple onload events as a potential problem... 

I have this code for the menuing system (still in use and fine)- 

if (window.addEventListener)
window.addEventListener("load", onloadfunction, false)
else if (window.attachEvent)
window.attachEvent("onload", onloadfunction)
else if (document.getElementById)
window.onload=onloadfunction

and this for the old scroller

window.onload=populate

Kinda messy but it used to work perfectly... but once again with only one piece of Javascript it's fine.

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase

The previous testcase didn't show the performance issue anymore. However this one still does.

Comment 6

[Martijn Wargers (dead)]

Attachment: testcase2

This page should not show anything red.

Comment 7

[Daniel Holbert [:dholbert]]

I think testcase2 is a separate issue that regressed since the 1.9.0 branch split off.  Using Linux, I see these results:

 * testcase1 (attachment 349854 [details]):
   -  takes 16000ms on both today's mozilla-central nightly and Firefox 3.0.4
   -  takes 2700ms on Firefox2.0.0.17
 * testcase2 (attachment 349858 [details]):
   - is red on today's mozilla-central nightly
   - is all white on both Firefox 3.0.4 and Firefox2.0.0.17

Comment 8

[Wayne Mery (:wsmwk)]

is http://www.voanews.com/english/2009-01-31-voa8.cfm an example of this?

40-50% cpu in FF 3.1b3, 6% in IE.

Comment 9

[Martijn Wargers (dead)]

Comment on attachment 349858 [details]
testcase2

Testcase2 doesn't show anything red anymore, so I guess that has been fixed.

Comment 10

[Martijn Wargers (dead)]

Ok, this is a lot better in current trunk build than it was in a build from 2006, so I think this is worksforme.