Aaron Kaluszka Reporter
	Description • 23 years ago

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1+)
Gecko/20010624

Look on the specified page.  Mouse over various buttons on the top and side of
the page.  DHTML is not very responsive and maxes CPU usage.  The code is
cross-platform and the equivalent functions are fast on NN4 and IE.  The farther
away the mouseover action is from the object being modified, the worse the
performance is.  

For example, run your mouse quickly over the 4 buttons under Online Resources. 
The performance is poor, but acceptable.  Now run it quickly over the 5 buttons
under Corporate Info.  The performance will be severly degraded.  Now, resize
your browser window in such a way that the bottom-right corner is close to the
Corporate Info section.  The performance will have increased.  

Performance should be the same at all locations.
DOM1 performance should also be at least on par with Netscape 4 DOM0.

	Vladimir Ermakov
	Comment 1 • 23 years ago

What do you mean by "performance"? Is it how fast links are changing to green
background, or how fast the "message div" appears? Because the "message div"
shows up instantaniously on my machine, the same way as on IE. 
 The only problem I see is that mouseover responds slower... not significantly
but slower. If you move your mouse from bottom up the green background sometimes
skips 5 lines or more. On IE its never more then 1.

	Aaron Kaluszka Reporter
	Comment 2 • 23 years ago

I'm talking about the message div (but you can see the effects on the GIFs)
The rate at which changes are recognized and occur.  It is especially apparent 
at the farthest point from the div, the top menu bar.  And the skipping of 
buttons is part of it.  Just watch at the update speed of the div.. its not 
really the appearing or disappearing itself, its the rate at which it can 
handle the change.  Also, if I don't tell it to go in the bottom right corner 
(it will default to top left corner) the speed is comparable to IE/NS4.  When 
it is working properly you won't see skipping.  Also check your resource usage, 
it will stay at 100% while doing mouseovers.

	Jano
	Comment 3 • 23 years ago

try www.efestival.hu the scroll effect is really not so smooth like in IE5

	Aaron Kaluszka Reporter
	Comment 4 • 23 years ago

Performance is even worse now... On the mentioned page, moving the mouse over
the sidebar triggered about 4 of the onmouseovers when moved relatively fast. 
Now it doesn't really trigger any unless you completely stop your mouse over them.

	Aaron Kaluszka Reporter
	Comment 5 • 23 years ago

In fact its so slow now, its hard to even see this bug in effect because
everything is _slow_.

	saari (gone)
	Comment 6 • 23 years ago

-> DHTML performance. Waterson if you care, give it to someone appropriate, this
is not an event system issue (at least I'm pretty sure it isn't)

	Aaron Kaluszka Reporter
	Comment 7 • 23 years ago

An animated GIF was added to the page, now DHTML peformance is exponentially 
worse.

	Aaron Kaluszka Reporter
	Comment 8 • 23 years ago

I don't see this bug anymore.  Perhaps the fixes to bug 118933 did the trick. 
I'd like to see some numbers before I close out this, though.

	Aaron Kaluszka Reporter
	Comment 9 • 23 years ago

The problem returns 2002020908

	Aaron Kaluszka Reporter
	Comment 10 • 23 years ago

well it went away for a few days -> regression

	Tom Mraz
	Comment 11 • 23 years ago

I don't see any differences between performance on the various buttons on the
page. The reaction isn't lightning fast but it's acceptable.
(Linux Mozilla 0.9.9).

	Aaron Kaluszka Reporter
	Comment 12 • 23 years ago

As stated in comment #5 and comment #7, the performace is so bad that you can't
even see the degredation because its too slow to compare.  The performance
practically makes the page unusable on my system (and there's no excuse on my
system which is Dual Athlon XP 1700+, 1GB ECC DDR266 RAM, Windows XP).
However, you can still test the degredation I believe, though its not exactly
what I had in mind upon original report.  Ex: If I run at 640x480, the page runs
acceptably (I suppose), but if I run at 1600x1200 (my normal res) the page
becomes nearly unusable.
If you want to see how it should be, try a Feb 2nd build.

	Johnny Stenback (:jst)
	Comment 13 • 23 years ago

Let's wait and see what bug 129115 does for this problem before we spend much
time on this.

	Aaron Kaluszka Reporter
	Comment 14 • 23 years ago

Okay, I've noticed something EXTREMELY interesting.  The page is question works
GREAT if I simply remove the background image.  Updating summary to reflect.  I
may make a test case for this soon.

	Markus Hübner
	Comment 15 • 23 years ago

There is a nice testcase from bug 135626 at 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=79797

	Aaron Kaluszka Reporter
	Comment 16 • 23 years ago

"But the testcase doesn't use any DHTML at all."

	Aaron Kaluszka Reporter
	Comment 17 • 23 years ago

Fix for bug 102321 helps this tremendously.  Performance is back to the
(originally reported) 20010624 level of performance.
If only we could get it to the 20020202 performance level.  Does anybody have
any ideas on why performance was so much better for those few days in Feb?

	Markus Hübner
	Comment 18 • 23 years ago

That goes hand in hand with the things seen on http://www.world-
direct.com/mozilla/dhtml/index.html
[ further info in bug 107746 ]
They were also fast as hell in those days of february!!
Really hope we can find out what happened there.

	Markus Hübner
	Comment 19 • 23 years ago

Fixing bug 102321 helped a bit - what do the individual tests say?

	Aaron Kaluszka Reporter
	Comment 20 • 22 years ago

updating URL.  problem is still present, though perhaps not as bad as it used to be.

	Vladimir Ermakov
	Comment 21 • 22 years ago

I see slow performance mosing over links at the top of the page:
"Citizens Telephone" "Citizens InterNET" etc...

	Markus Hübner
	Comment 22 • 22 years ago

Using trunk build 2002122808 there is a considerable delay when mousing over 
the the menus on the left (with CPU usage 100%).
When mousing over the links at the top the mouse cursor even jumps around.
Reassigning to kmcclusk as he did some work in that area.

	Kevin McCluskey (gone) Assignee
	Comment 23 • 22 years ago

nsbeta1-.

	Boris Zbarsky [:bzbarsky]
	Comment 24 • 21 years ago

aaron, how about that testcase you were going to write?

	Boris Zbarsky [:bzbarsky]
	Comment 25 • 21 years ago

OK.  No testcase, no way to reproduce, lots of irrelevant comments, bug has
mutated OSes and become useless (for example, I see no issue on Linux on that page).

Marking worksforme.  If there is a site or testcase showing the problem, please
file a bug with that testcase attached, and make sure not to cc the usual
noise-makers.

	Aaron Kaluszka Reporter
	Comment 26 • 21 years ago

The page has been changed since... I can get a testcase up next week assuming
the problem still exists.