Closed
Bug 147796
Opened 23 years ago
Closed 2 years ago
Browser very slow when background color rotation with javascript
Categories
(Core Graveyard :: GFX, defect, P4)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
Future
People
(Reporter: ccomb, Assigned: kmcclusk)
Details
(Keywords: perf, testcase)
Attachments
(1 file)
|
559 bytes,
text/html
|
Details |
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.
----------------------------------------
<html>
<head>
<title>Test color rotation</title>
<script>
cx=0
function rotateColors(element) {
var el=document.getElementById(element)
cx++;
ca=Math.round(20*Math.sin(cx/90)+200)
cb=Math.round(20*Math.sin(cx/70)+200)
cc=Math.round(20*Math.sin(cx/50)+200)
el.style.backgroundColor="rgb("+ca+","+cb+","+cc+")"
}
function initButton(el) {
var tst=document.getElementById(el)
if (tst) setInterval("rotateColors('"+el+"')","20")
}
</script>
</head>
<body id="bod" onload="initButton('bod')">
</body>
</html>
-----------------------------------------------
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...??
|
||
Comment 1•23 years ago
|
||
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%
|
||
Updated•23 years ago
|
|
||
Comment 3•23 years ago
|
||
wfm using build 2002052809 on Win2k (trunk), CPU ~ 15% (PIII 900).
|
Reporter | |
Comment 4•23 years ago
|
||
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.
|
|
||
Comment 6•23 years ago
|
||
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
|
|
||
Comment 7•23 years ago
|
||
Setting default owner and QA -
Assignee: rogerl → kmcclusk
QA Contact: pschwartau → petersen
|
||
Comment 8•23 years ago
|
||
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
|
|
||
Comment 9•23 years ago
|
||
Unless you're running IE under X, the IE number is completely useless.
|
|
||
Comment 10•23 years ago
|
||
And why is that? This is not a Linux-specific problem. (OS=All) It may,
however, be an NVidia-specific problem.
|
|
||
Comment 11•23 years ago
|
||
regarding comment 2: Low CPU usage was observed with a nvidia card (GF3/Ti200)
and nvidia Linux driver 1.0-2880
|
|
Reporter | |
Comment 12•23 years ago
|
||
(from reporter)
Please note that I use a matrox card (g400 in xinerama mode).
I dont have any nvidia.
|
|
||
Comment 13•23 years ago
|
||
Aaron, are _you_ seeing this problem on Windows?
If so, there is a good chance that there are two separate bugs here, actually...
|
|
||
Comment 14•23 years ago
|
||
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.
|
|
||
Comment 15•23 years ago
|
||
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?
|
|
Assignee | |
Updated•23 years ago
|
Priority: -- → P4
Target Milestone: --- → Future
|
|
Reporter | |
Comment 16•21 years ago
|
||
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%.
|
|
||
Comment 17•21 years ago
|
||
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....
|
||
Updated•17 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•