Closed Bug 147796 Opened 23 years ago Closed 4 months ago

Browser very slow when background color rotation with javascript


(Core Graveyard :: GFX, defect, P4)



(Not tracked)



(Reporter: ccomb, Assigned: kmcclusk)


(Keywords: perf, testcase)


(1 file)

Just try to display the simple code below in the browser.
The browser just do the right thing (background color rotation),
but is almost unusable because it is slowed down very much. It takes then 5
secons to display a menu on a dual-pIII 1GHz.

  <title>Test color rotation</title>
function rotateColors(element) {
	var el=document.getElementById(element)

function initButton(el) {
	var tst=document.getElementById(el)
	if (tst) setInterval("rotateColors('"+el+"')","20")
<body id="bod" onload="initButton('bod')">

For information :
with netscape 4.7 : does not work
with opera 5 : does not work
with IE5 : works good, and the browser does not slow down.

PS : I have entered this bug against javascript engine, but it mights also be
the display engine that takes too much time to set the background color...??
Attached file testcase
Attachment is the HTML Code provided by the reporter..

The JS eats about 20% of the CPU (iBook2 - 600mhz G3 CPU)
Please always include build ID in bug-reports.
WFM. I don't see any slowdown testing with a current trunk CVS build, Linux
CPU usage at 0.1%
Keywords: perf, testcase
wfm using build 2002052809 on Win2k (trunk), CPU ~ 15% (PIII 900).
I'm at 15% CPU on mozilla,
but I reach 99% on Xfree (4.1.0 on redhat 6.2)

All this depends on the size of the window. If I try it on a small window, I get
15% on both Xfree and mozilla, but if I set the window to the full screen
(1280x1024), it goes to 100% cpu on Xfree.

Other running programs always keep a correct behaviour.
Horrible preformance here with 2002052709 1.0rc3 on Debian with XFree 3.I get
10% CPU used by XF86_SVGA even if I increase the value in setInterval from 20 to
200 (and the change of the color becomes hardly noticeable). With the original
value I must wait some 20 seconds for the cursor to move to a new position.
Obviously the severity of the problem depends a lot upon the version of the
XFree package and possibly on the graphics card, but I think it is obvious that
Mozilla somehow floods too many requests to X.
To compositor.  I suspect that X is just not handling 50 full-screen redraws 
per second (which is what the original testcase does).

People seeing this problem should try running quake at 50fps at full-screen and 
seeing what it looks like...  If that's a lot faster than Mozilla, we have a 
problem here.
Component: JavaScript Engine → GFX Compositor
Setting default owner and QA -
Assignee: rogerl → kmcclusk
QA Contact: pschwartau → petersen
Confirming since I see this
It completely pegs one of my Dual Athlon XP 1700+'s
WinXP/NVidia GeForce 2MX/1600x1200 32-bit
It uses 0% in IE.

Is this another NVidia thing or not?
Ever confirmed: true
OS: Linux → All
Unless you're running IE under X, the IE number is completely useless.
And why is that?  This is not a Linux-specific problem. (OS=All)  It may,
however, be an NVidia-specific problem.
regarding comment 2: Low CPU usage was observed with a nvidia card (GF3/Ti200)
and nvidia Linux driver 1.0-2880
(from reporter)
Please note that I use a matrox card (g400 in xinerama mode).
I dont have any nvidia.
Aaron, are _you_ seeing this problem on Windows?

If so, there is a good chance that there are two separate bugs here, actually...
I do, but I assumed the reporter did too since he also gave IE stats.
The weird thing is that I see it on my home computer (Dual Athlon XP 1700+,
WinXP, NVidia GeForce 2MX, 1600x1200 32-bit)
but I don't see it with my (less powerful) work computer (P-III 600, WinXP,
NVidia Riva TNT2, 1280x1024 32-bit)
so ignore my NVidia comments from before
I'm not sure what's going on here, but it may very well be two different bugs.
If my window size is near 1600x1200 or larger Mozilla pegs the CPU, otherwise it
doesn't.  Also, I got the 1600x1200 window to not peg the CPU by lowering my
resolution and then increasing it again.  Very weird.  Does the repaint code not
handle large windows for some reason?  Should I open another bug for this?
Priority: -- → P4
Target Milestone: --- → Future
Almost 3 years after, I'm still seeing this problem at least with :
- moz 1.7.5 on Debian Sarge
- Firefox 1.0 on winXP
For both, I get 100% CPU when the browser takes the full page.

With IE6, I get only 10%.
With Opera7 on linux, I also get 100%
With Konqueror on linux, I get about 80%.

Fwiw, when I run this on Linux, X takes about 80% of the CPU.  Mozilla takes
about 5%.

So it's not so much a browser issue as an X one, I would say....
Product: Core → Core Graveyard
Closed: 4 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.