Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 21762 - tracking: poor performance using DHTML
: tracking: poor performance using DHTML
Status: NEW
: dom0, meta, perf, top100
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: P2 normal with 128 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
sample 13
: 77456 78826 98066 98627 100453 110029 110246 124047 (view as bug list)
Depends on: 77948 87165 118933 136688 137577 140789 142994 164084 186465 210525 212831 218650 229391 291386 12761 21879 38378 46257 64516 65509 69354 69803 70100 70156 74826 75121 78826 81567 82924 83088 83536 84891 87808 93766 95007 97287 97938 98066 98627 98828 102321 104593 106796 107634 107746 110029 110246 115247 117061 117436 117601 js-perf 123668 100%CPU-bg 124178 124683 124685 124686 125205 128901 129115 129496 129953 131400 137584 139445 139986 140167 149216 154568 155160 x-files 157401 157406 157681 159512 164931 169247 169531 169748 170272 170330 170702 177958 186133 188331 190193 191474 193849 194627 195408 195883 197341 199630 201082 203698 210602 212264 213813 220937 234233 243725 243726 267179 297294
Blocks: 71668 advocacybugs 103712 142969 164421 396574
  Show dependency treegraph
Reported: 1999-12-14 16:37 PST by buster
Modified: 2016-08-31 10:27 PDT (History)
119 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Original file referenced from URL field all this time (4.80 KB, text/html)
2002-06-08 23:20 PDT, Jacob Kjome
no flags Details
A testcase for resizing of the document body (950 bytes, text/html)
2002-06-20 06:03 PDT, Tomasz Krysinski
no flags Details
DHTML Width Animation (1.57 KB, application/xhtml+xml)
2010-09-04 17:09 PDT, John A. Bilicki III
no flags Details

Description buster 1999-12-14 16:37:32 PST
from the layout newsgroup:

What's with the Slow javascript interpretation lately.

I am viewing everything mentioned below with the most current Win32
build (1999121314) on Windows 2000 RC3 (build 2183)

The DHTML demo ( #13 in the DEBUG viewer DEMO's) used to run pretty
smoothly on my PIII 450 at work.  Now it runs like mollasses and takes
up all my system resources.  Even just moving the mouse around the
desktop is painfully slow when it is running.

Now, it did run like mollasses on my PII 266 at home and still does
even more so now.  It really seems like PII 266 should be able to run
something like this.

Also, check out this page:

It is based off of a tutorial of the W3C DOM at:  (these demos include ending of
document.write("/script") where it should be
document.write("\/script") to escape the end script, but that is
another topic...)

Try clicking on the links  "Try It" and "Stop It".  They start and
stop a script meant to begin the movement of a block of text in a
<div> tag kitty corner from lower left to upper right.  The script
runs, but it does so  after a few seconds of thinking about it.
Certainly the "stop it" script actually stops it at least 5 seconds
after it has been clicked.

Also, check at the top of the page.  Look at the "Click me..." links.
They hide and make reappear the top to headers.  This works in IE5 and
follows the W3C dom.  Back when you still had some more debugging
turned on, there were messages saying that I couildn't "execute
scripts that are not in my own domain" or something like that.  It was
a javasript security error.  Now, those javasript debug messages
aren't shown anymore and the links still don't work.

To see what the expected results of this page are, please view it in
IE5.  Everything works as expected and that is easier to understand
than me explaining every bit of it.

If you do nothing else, please make the scripting work as well or
better than IE5.  I think the success of this browser depends on the
script interpretation abilities.  There are plenty of browsers out
there that display HTML just fine.  Mozilla5 does this pretty well
already, but NOONE will move to Mozilla5 if the scripting and DOM
model don't work as expected and/or have bad performance.

DHTML is THE reason why this browser is being built, as far as I'm
concerned.  So, please don't forget this and make it kick some ass!


Comment 1 vidur (gone) 1999-12-14 18:00:59 PST
I don't see a noticeable difference in performance in either of test cases using
the build 1999121321. Maybe a small rift in the space-time continuum? Marking
Comment 2 Mike Shaver (:shaver -- probably not reading bugmail closely) 1999-12-14 22:02:59 PST
Is this a dup of 12761?
Comment 3 Jacob Kjome 1999-12-15 07:36:59 PST
You've got to be kidding me!!!!   What are you comparing this to?  Honestly, go
to a machine with IE5 and look at the site that I mentioned ( ).  Now, compare it to the current Mozilla
build.  There is no "small rift in the space-time continuum".  Everything is
faster in IE5 and there are certain things that simply don't work in Mozilla
that work in IE5. Try out all the different things I described in my newsgroup
post.  Keep in mind, you need to compare this to the current leader in the
browser market, Microsoft with IE5.  Did you really look at it, or did you take
a quick glance at the page?  Did you try out the DHTML demo (#13)???

There are some things that simply don't work like the "Click me" links I
described in my news post.  Really, it does NOT work.  I guarantee it.  If it
does, then you have some secret different build than the rest of the world
has.  I've tested this at work and at home.  Same results.

Also, what speed of CPU did you test on?  My machine at home in a PII 266 with
60ns 128 meg of RAM and a 66 mhz bus.   My machine at work is a PIII 450 with
128 meg of PC100 RAM and 100 mhz bus.  My machine at home is a bit less powered
than the new machines, but it runs everything else just fine and plenty fast.
It most certainly runs scripts in IE5 plently fast, but not Mozilla.  Really,
I'm not making this up.  I want Mozilla to kick IE5's ass.  Believe me.  I'm
not trying to pester, but when you say "WORKSFORME" I have to think wonder
what "WORKSFORME" means:  that it works?  or does it work well and fast???
That is the question.

Sorry for the rant... just want a good browser.

Comment 4 chrisn 1999-12-15 09:29:59 PST
Confirmation of issues with this bug:

I tried this in the IE 5.5 beta and the latest daily build available, 12-14, on
a P2-400 with Win98 and 128M of RAM.

I'm looking at this site:

First, speed:

Expanding/Contracting text:

When you first visit the page, the expanding/contracting text runs slightly
faster than IE5.5, however, if you click the "try it" link above the expanding
text, then click the "stop it" link, the expanding/contracting text moves about
twice as fast on Mozilla as in IE5.5. Yes, that's right, _at least_ twice as
fast. This runs contrary to the initial bug report below. This speedup occurs
whether or not the problems described in the next paragraph occur.

The problems: First, the behavior of the page when you click the "try it" link
is erratic. When you click the link, a small div with some text moves back and
forth on the page, as the paragraph below continues to expand  and contract.
Sometimes the page runs smoothly during these operations, but most of the time
(80%) the page starts stuttering: the little moving box moves in fits and
starts, and the expanding/contracting text moves much slower than usual. Also
during this time when things are moving slowly, if you click the "stop it" link
the page doesn't respond as quickly as it should (there is sometimes a definite
lag before the moving div stops). Also, curiously, sometimes this lag appears
even if everything on the page is running smoothly.

20% of the time I don't see the problems above.

Next, the "Click Me" links don't work. I've filed bug 21797 on this. It might be
a problem with the Javascript itself, and not with Mozilla, but I don't know
enough about it to say one way or another.

IMO, there are still issues on this page regarding performance, so I have
reopened this bug.
Comment 5 vidur (gone) 1999-12-15 11:11:59 PST
OK, I'll accept the bug and acknowledge that there are performance issues
related to DHTML animation that we need to deal with. The original wording of
the bug implied that there was recent performance degradation - I haven't seen
any large changes in the last several weeks. There's no question, though, that
we need to do some profiling to figure out what our bottlenecks are. Ccing beard
and kmcclusk since I believe that the view manager plays are large role in this.

Jake and Chris, thanks for pushing the performance issues. While we're still
dealing with initial loading performance, animation-related issues are still
very important.
Comment 6 leger 1999-12-15 16:46:59 PST
Clearing WORKSFORME resolution due to reopen.
Comment 7 vidur (gone) 1999-12-21 18:48:59 PST
The performance issues here may be similar to the ones for bug 12761.
Comment 8 ekrock's old account (dead) 2000-01-05 16:13:59 PST
Marking [PERF].
Comment 9 vidur (gone) 2000-03-09 14:02:52 PST
Things are looking better after Michael Lowe's timer work. I'd like to keep this 
open as a tracking bug. Still hoping for responses from the View guys.
Comment 10 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-05-07 11:42:31 PDT
I'm tracking down some optimizations that might make JS animations faster.  I'll
attach a patch to 32378 in the near future that includes the fix for 21879, and
which should help things a reasonable amount.

(Once I stop breaking menus and tooltips, of course.)
Comment 11 Bruce Mitchener 2000-05-07 11:52:41 PDT
Did you really mean 32378?
Comment 12 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-05-09 09:12:59 PDT
No, I'm a moron: 38378.
Comment 13 vidur (gone) 2000-06-23 14:38:00 PDT
I'm still keeping this open as a tracking bug for animation performance work 
that I hope will happen for nsbeta3.
Comment 14 jsnod 2000-07-18 16:20:01 PDT
We're having problems with DHTML animations at:

The layers simply do not display.  The code was all generated with Dreamweaver.
 My question is, is this a problem with our code, or a problem with Mozilla?
Comment 15 ekrock's old account (dead) 2000-07-26 18:55:22 PDT
Vidur, if this is *truly* a tracking bug as opposed to a bug in its own right,
could you please remove the nsbeta3 nomination? In general, only "real" bugs
should get nsbeta3, not meta/tracking bugs. It would be better to nominate each
individual tracked bug so we can accurately track the number of real outstanding
Comment 16 Nisheeth Ranjan 2000-08-16 14:37:09 PDT
We are making the conscious decision of attacking performance problems with 
DHTML animations post netscape 6.

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration, but do not clear 
the nsbeta3- nomination.
Comment 17 rob cherny 2000-11-30 22:59:43 PST
ok, *really not* trying to be a jerk ... we're post ns6 ... just so happens this
one is near and dear to my heart ... sorry.

any plan of attack? also, I guess a question: does this specifically (as it
says) target only animations, or DHTML performance in general? display,
hide/show, calculations on positioning, etc?
Comment 18 selmer (gone) 2001-03-15 23:47:13 PST
So, what's the deal with this bug?  The tracked bugs are both closed.  No
activity in a long time.  Is there anything left to do?
Comment 19 Ronald van Kuijk 2001-03-16 12:18:01 PST
If you compare on NS4.x and Mozilla,
I think some work still has to be done..
Comment 20 Ronald van Kuijk 2001-03-16 12:40:15 PST
Or look at the bouncing text example on

The diference between NS4.x/IE and Mozilla is huge..

Still I think mozilla is a great product.
Comment 21 James Green 2001-05-27 10:22:12 PDT
Our DHTML test #13 hangs my linux build; takes several seconds to respond to UI
events. Marking All/All.
Comment 22 Aaron Kaluszka 2001-06-09 09:37:37 PDT
Pre-M3 (before the bulk of the interface was designed) test13.html used to run
great on my P-133/16MB RAM/Win98 with viewer.exe..  Now, years later, on my
K6-III-500/192MB RAM/WinXP, the speed has returned, but then Mozilla uses 80-90%
of my CPU.  I would guess that it would be too hard to track the difference
between M2 and 0.9.x, but maybe the difference between M2 and M3 would show the
problem?  Though I'm sure there are way too many dependencies now to regress..
Comment 23 Grey Hodge (jX) 2001-09-13 11:32:10 PDT
Adding bug 98828 to thedependency list. It's marked "fixed" as of 9-10-2001 so
it won't hold this up in the future, but is related, and seems to be generating
some interest amongst people.
Comment 24 Sivakiran Tummala 2001-10-15 11:26:34 PDT
mozilla renders the homepage slowly compared to IE5.x on windows 2000  
Comment 25 Sivakiran Tummala 2001-10-15 11:29:17 PDT
adding the keyword top100 as sony is one of the top100 sites.
Comment 26 Sivakiran Tummala 2001-10-15 11:32:10 PDT
adding myself to cc list
Comment 27 Markus Hübner 2001-10-18 07:50:45 PDT and are among the top 10 sites in 
the (web)design community.
The DHTML performance of the news-scrollers are terrible, causing major 
Comment 28 Jiri Znamenacek 2001-10-21 08:39:49 PDT
I've just look closer at the fantastic IEemu series at (thanks
to Mozilla for to be able to do this!) and found out something interesting.
Sorry if it's already known.

GenericMove ( works awsome.

GenericResize ( on the second DIV
like charm, on the first very terrible. So I dag into the code and found out
that the first DIV contains another DIV, which used CSS rule "overflow: auto;".
When this rule is commented out, Mozilla starts to work as 100m sprinter world

I think the JavaScript sroller from the above two pages are of the same type. I
didn't look at the code but I uses similar somewhere and it's based on "clip"
CSS property.

Hope this helps.
Comment 29 Henrik Gemal 2001-10-24 08:05:08 PDT
another sites with bad performance:
Comment 30 Jeff Rouyer 2001-10-24 12:13:37 PDT
DHTML Performance.

For me this is the number one hang-up for Mozilla for the past two years, and
unfortunately the performance seems to be getting worse. It is also not
mentioned in the Mozilla 1.0 Manifesto. We have over 5 years of performance
comparisons to rely on starting with the early version of Netscape 4 and IE4.
The performance of Mozilla must equal or exceed this legacy DHTML performance.
Equalling the performace of the latest flavor of Netscape 4.x should be the
baseline without question. I have a mailing list of over 8,000 DHTML Web
developers that feel even more strongly about this than I do.

For testing I am using the homepage portion of my portfolio site which has been
coded for 4.x, 5.x and 6.x browsers.
Comment 31 Eddie Traversa 2001-10-24 13:17:37 PDT
Like Jeff Rouyer I also wanted to express my dismay at the state of DHTML
performance with mozilla.  We need this bug to be assigned with a #1 priority
and be fixed as quickly as possible.  An example of the poor performance can be
seen from my home page which is DHTML intensive to say the least but runs fine
on IE5+.  The site is coded to DOM standards wherever possible.  I suggest
comparing the performance with IE and Mozilla as a measure of what needs to be done 

Eddie Traversa
Comment 32 Ronald van Kuijk 2001-10-24 14:10:06 PDT
Funny thing that so many people complain and the number of votes is only 7. I
agree that that the dhtml performance is not good, but atleast I voted. Maybe we
should 'mobilize' some people and get the number of votes up. A mention on
mozillazine could help maybe. 

Further... Mozilla rocks..
Comment 33 Stephen Anderson 2001-10-24 14:48:12 PDT
I could be wrong, but I think it would be more productive if we focused our
efforts on resolving the bugs that this "tracking" bug depends on, rather than
commenting on this bug directly. We all know the DHTML performance sucks, but we
should isolate specific techniques or issues that cause the performance
problems, target them with individual bugs, and resolve them one at a time. 
Just my $0.02.
Comment 34 Håkan Waara 2001-10-24 14:54:10 PDT
I would suggest interested parties mobilize in newsgroups and chats, and try to
solve the problems we have. It's not an impossibility to create a patch if, say
5 interested people co-operate to fix a bug.
Comment 35 al sparber 2001-10-24 17:57:47 PDT
I've been publicizing the DHTML problems for months with little or no 
acknowledgment from Netscape and Mozilla people. In fact, many have outright 
denied the problems even exist. I have a similar bug report (100206) posted for 
me by Eric Meyer. Take this seriously folks, or be prepared for a stillbirth. 
The time has come to face reality. Show us you can make it work.
Comment 36 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-10-24 18:10:07 PDT
Speaking as one of the Netscape/Mozilla people who burned more than one
all-nighter chasing this stuff through Quantify and jprof and the debugger, I'd
just like to say:


Mozilla performance, DHTML and otherwise, has improved dramatically since this
bug was filed, and continues to improve.

If you want to help, use the tools listed at and file individual bugs with
profiling data for individual, minimal test cases.  (That means an attachment to
the bug that does only the absolute minimum needed to reproduce the performance
problem -- most of the sites listed in this bug have a _lot_ going on, and that
means that an engineer has to burn, often, several hours just to isolate the
problem more closely.)

Help us help you.  Or, if you can't be bothered to help, please complain
somewhere other than in this bug.  Some of us take our bugmail seriously, and
the time spent reading about how this has bothered you for years, but you
haven't tried to help out, is time we can't be spending making this damned thing
(Apologies to those who _have_ done good detective work, like the gent who
discovered that "overflow: auto" was specifically causing us pain.  You are the
wind beneath my wings.)
Comment 37 Eddie Traversa 2001-10-24 19:24:17 PDT
Yes Mike, its improved so significantly that the simplest DHTML animation 
pushes the cpu to 100% in mozilla.

So please dont come at us with "that its improving" when clearly it is not. It 
has regressed and continues to regress significantly, and that is what the 
DHTML community is concerned about.  

Let me spell out the performance issues here for you so that its simplified:

1. Whenever something is offscreen with mozilla it pushes the cpu to 100%
2. If you put an animation in a loop it pushes the cpu upward. Not so in IE or 
3. If you have multiple animations at once in mozilla it pushes the cpu 
upward, more so than IE and NS4 or even earlier versions of mozilla and NS6. 

I will file more simple test cases on the above issues shortly.

Clearly these are show stopper bugs as far as DHTML goes. Showstopper to us 
means we will not support this browser unless the browser improves 

Suggest you pull your ego in and stop criticising people who are trying to 
make mozilla aware of the DHTML issues, thus making it a better and more 
viable browser, and get on with the job of fixing the browser instead. 
Comment 38 aaron boodman 2001-10-24 19:25:48 PDT
re: the overflow: thing. 

I wrote the scroller at, and have spent a great amount of time 
writing dhtml in general - for mozilla as well as IE and the other dhtml-
capable browsers.

To my eyes, the major performance issue(s) left in mozilla are all related to 
the overflow and clip css properties. Note that I am not a browser programmer, 
so this is all just based on what I can see as a script author. But DHTML 
performance for me is quite good in the builds post .91 so long as no elements 
extend beyond the viewable area of their parent.

Whenever that happens - whether you are using overflow:hidden or overflow:auto 
or clip:whatever -- you will get serious performance hangups.

A good example of this is at -- 
in that directory you will find a number of dhtml examples for a drag library i 
wrote. Note that every example runs splendidly in mozilla except the one with 
the overflowed content - ex4.html.

I do understand that the examples are more complex than testcases should be, 
but i think that it is clear that the variable that is causing the performance 
drain here is the overflow. This is consistent with every other dhtml problem I 
have run into on with mozilla, as well as most every performance 
problem I have seen out on the net with mozilla from other DHTML developers.

I am totally guessing here - but i really think this problem is a more general 
layout problem related to 52063 and 46257. It seems like Mozilla doesn't know 
that when data overflows and element, and that data is hidden with 
overflow:auto or hidden, that that changing the contents of that element cannot 
effect the parent elements. So it is wasting alot of cycles recalculating the 
whole page for no reason. This is consistent with the fact that in the two 
mentioned css bugs, the contents of the element are clipped but scrollbars 
still appear in the parent elements -- mozilla thinks the contents of the 
clipped elements still needs to be taken into account.

sorry for my long-windedness here, but this is an issue dear to my heart as 
well. Every dhtml developer would love to see it fixed.


Aaron Boodman
Comment 39 Eddie Traversa 2001-10-24 19:30:49 PDT
part of it is due to the overflow bug, other parts are not.  Let me get some 
test cases together so we can get on top of this more thoroughly. 
Comment 40 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-10-24 19:34:43 PDT
Are you using some kind of proxy that's changing your bugmail?  I didn't say
that it was done.  I'm not surprised that there are still cases that we suck at.
 I'm not surprised that there are a lot of them.

I _said_ -- and I can produce testcases and measurements to back it up, if you
want to take this outside -- that it had improved dramatically.  That the
overflow:auto case is still bad is not evidence to the contrary, just evidence
that we still have work to do.  Note that this bug isn't closed.
Please _do_ file minimal test cases for these bugs.  It makes it many times
easier to get the fixing done.
I don't have a lot of ego invested in Mozilla's DHTML performance, I assure you.
 But if you look at this bug, and the number of dependent bugs, and the number
of comments in them, I wonder how you think it's helpful to keep hammering on
that point over and over again, without additional detail or refinement of the
provided information.
You mention regression, though, and I find that especially interesting.  When
did Mozilla behave better on those pages?  Knowing when the got worse would be
_very_  helpful data in tracking down the problem.

(I love you, Aaron Boodman.)
Comment 41 Brendan Eich [:brendan] 2001-10-24 19:53:34 PDT
Whose ego started this, anyway?

>------- Additional Comments From al sparber 2001-10-24 17:57 -------
>I've been publicizing the DHTML problems for months with little or no
>acknowledgment from Netscape and Mozilla people.

There is no "I" in "DHTML", but bully for you.

>In fact, many have outright denied the problems even exist.

Many at  Name names, back up your calumny or retract it.

>I have a similar bug report (100206) posted
>for  me by Eric Meyer.

Eric Meyer of Netscape?  Not one of the many, apparently.

>Take this seriously folks, or be prepared for a
>stillbirth. The time has come to face reality. Show us you can make it work.

Try being helpful, not threatening -- the same people hacking on performance and
footprint can't also fix DHTML.  Maybe we should take some of the folks hacking
XHTML support and have them work on improving DHTML.  I personally think DHTML
is more important now and in the next few years than XHTML.  I'm sure I'll be
flamed for writing that, and some of you want both -- but there ain't no free lunch.

Vidur was part of the group that did DHTML support in 4.x, and it was well-done
(albeit non-standard, but that happened after most of the code was written,
IIRC).   Maybe we can revive some of the techniques, if not the actual code,
based on what measurement of Mozilla reveals.  Who knows?  But inflammatory,
egotistical  declarations and threats in this bug do not help.

Comment 42 Eddie Traversa 2001-10-24 19:59:51 PDT
Ok Mike 

Sorry for the rant! This issue is very meaningful to me as it is to a number 
of developers.  

Im using sympatico, i believe that may be on a proxy.  Yes I know  when this 
bug started appearing but cant remember the correct terms you guys use. So let 
me make a crude attempt at explaining.  It was when the image cache ( i think 
thats the correct term) and some other major improvements were done to 
mozilla.  You can check back to NS6 and see that in fact the animations 
performance on this browser is superior to IE for most parts. 

let me get some more test cases together for you, I am doing that now..

Comment 43 al sparber 2001-10-24 20:02:18 PDT
You should be ashamed of yourself for being so cavalier. "Whatever"? Hey... 
just fix it for once. I've been talking about these bugs for a very long time. 
These bugs have been documented for a very long time. You should have enough 
engineers to fix the problems. Here is a test page done specifically to help 

It should be self documenting. Please... I really want to see Mozilla succeed, 
but there are already 3 broken Netscape 6x browsers out there that are severely 
complicating the issue.

I sincerely hope this helps.
Comment 44 Eddie Traversa 2001-10-24 20:44:45 PDT
Ok here are a couple of more test cases, this time using path animations. the 
first one pushes a gif image from off screen to on screen

the second starts the animation from an on screen position, where you would 
expect the cpu to be lower for mozilla than it currently is.

On my machine I get a peak of 32% on the cpu for IE6 while mozilla is over 
double that when on screen and hits 100% when off screen. If there were 
multiple animations occuring at once this problem would be compounded. But 
lets work on these first, my hunch is if we can get these fixed then the rest 
will fall into place.   

Was the image lib the term I was trying to remember??  

Eddie Traversa
Comment 45 WD 2001-10-25 05:40:31 PDT
For me, the above 2 samples use approx. 17% CPU time with either Mozilla or IE.
  On or off-screeen doesn't seem to make much difference.   The movement in both
IE and Mozilla are a bit jerky.

Athlon 700 
Moz 2001102403
IE 5.0 SP1
Comment 46 jojo caine 2001-10-25 06:35:16 PDT
Hi, well I don't know how you get those results.
The two tests submitted by Eddie Traversa, typically run at 30 to 55% CPU usage
rising to plus 80%+ as the flower goes off screen to the right, more noticable
in demo 2 as the flower moves further off screen.

The same pages viewed with IE6 are smoother, with CPU usage typically below 10%
rising on occasins to 22%.

With regard to Al Sparbers demo; as soon as I hit the scroller CPU usage goes
straight to 100%. My system became unstable and I had to close Mozilla.

Again with IE6 Al's scroller never forced the CPU above 4%

Moz build: 2001101117

System Win2k, 1.2 ghz T'bird, 1012 mbRAM with SP2

I use Mozilla for most of my browsing, but the dhtml issues cause great concern.
Comment 47 Markus Hübner 2001-10-25 06:39:58 PDT
confirming the same as jo jo - using a PentiumIII 600MHZ, 327RAM, using MSIE6.0 
and build 2001102403 on win2k with SP2.
Comment 48 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-10-25 15:09:18 PDT
To flame Brendan ;), XHTML is not just a future thing:

"All of our development work for the new is...W3C standard," said Bob
Visse, the director of MSN marketing..."

"We do identify the string from the browser, and the only issue that we have is
that the Opera browser doesn't support the latest XHTML standard," said Visse."

This is from a CNet article about MSN blocking certain browsers from the site.

PS. I do want both XHTML and good DHTML perf, and as the article above and this
bug report demonstrate, we NEED both. Things need to be balanced out.
Comment 49 al sparber 2001-10-25 22:43:15 PDT
"PS. I do want both XHTML and good DHTML perf, and as the article above and this
bug report demonstrate, we NEED both. Things need to be balanced out."

I agree. But the word "balanced" seems a bit noncommittal and pathed towards 
deference :-)

The DHTML issues are important, as are the XHTML issues. However, one cannot 
be "fixed" at the expense of the other lest the good folks at Netscape release 
another 6x browser that is incomplete and inferior to its competition.

The processor spikes apparent in the demos seem to me on the surface to 
indicate that there is a familial tie between the Navigator 4 and Mozilla 
engines... with respect to GIFs.

I am very curious why this problem is so exacerbated on the Win2k/XP platforms. 
It almost seems like the browser can't keep up with the OS/video subsystem. The 
scroller on the test page I posted operates as smoothly as native OS controls 
on our Win2k and XP test machines in IE6, NN4, and Opera 5.12. It's downright 
frustrating when we run it in Moz.

By the way... that wasn't intended as a threat in my last post. I really do 
want to see Moz succeed... but we have an awful lot riding on DHTML and you 
know how people are. The average Joe who has happened upon a copy of Netscape 6 
is not going to want to hear the esoterica about why this page or that doesn't 
work well... he just wants it to work.

If you haven't already discovered this... bumping the script timeout to 50ms or 
higher, cures the problem... but this is not a solution. Moz on Win2k should 
handle any timeout just like IE and OPera do. We use sniffers to detect and set 
timeout based on OS as all browsers on win9x need a longer timeout.

-Al Sparber
Comment 50 Eddie Traversa 2001-10-26 02:16:53 PDT
I think the gif issue is one bug and the performance issue is different again. 
eg, it doesnt matter whether I am pusing around a gif or jpg or png, mozilla 
still has problems with its cpu consumption and consequently adversly affects 
DHTML animations. Yet at the same time, there are some gif related issues that 
also need to be addressed. I think its important to now begin to make some 
distictions here and isolate the issues as much as possible. 

Ill do a demo at some point tommorow that just uses some text animations to 
illustrate the problem further. Ill try and do it in a way that can demostrate 
how mozilla degrades performance wise when it tries to run multiple animations.

Comment 51 Eddie Traversa 2001-10-26 20:41:46 PDT
In this animated menu example, the menus are not showing up at all on 
milestone 0.9.5 but are on NS6.1 and IE6

maybe this is something not related to performance?  
Comment 52 Eddie Traversa 2001-10-27 00:55:53 PDT
The animated menu example isnt a bug, rather an oversight on my behalf in not 
browser sniffing for mozilla. Got it working now.  
Comment 53 Ken Ford 2001-10-27 11:19:23 PDT
This is a pretty simple page that is very sluggish compared to IE 6 and NS 4.78 
and makes my CPU usage jump to about 75%.
Comment 54 Eddie Traversa 2001-10-27 12:32:29 PDT
That show/ hide menu example that Ken just posted is an interesting one. First 
I get similar results to what Ken gets, but what is interesting to me is when 
you compare it to  

On the animated menus, I get really good performance with moz comparable to 
IE6 on win XP. That is anti-intuitive as you would expect the animated menus 
to do poorly in comparison to the show / hide example.  

I think what maybe useful is to start getting a list together sort of along 
these lines;

Simple linear animation:

Uses a timer set to 1 ms to increment the position of the layer by 2. 

Onscreen performance of this animation method is comparable to IE. Off screen 
it shoots upwards in moz. 

Path Animation:

Uses a timer set to 50 to increment the position of the layer with predefined 
points pushing text.

Onscreen performance peaks about 10% higher than IE and offscreen performance 
peaks about 25% -30% higher than IE

Using an image instead of text sees the onscreen performance increase by a 
further 25%

Show/hide menus

No timer, loops through an array and shows / hides layers on user mouse events.

Performance significantly worse than moz.

Animated menus

Uses timers set at 50 and 45 respectively, clipping animation technique used, 
increments and decrements clipping region of layers 10 pixels at a time 
through timers.

Moz performance equivocal to IE6

Doing something along these lines may pinpoint where the problem originated 
from as we can then look for commonalties and differences between the 
different examples. What do you guys and gals from mozilla think? 

Comment 55 Eddie Traversa 2001-10-27 12:39:43 PDT
Just to add further, 

There is an animated menu example here that uses images  

same code as previous animated menu example, just uses images instead of soild 

While there seems to have a bug in the way it renders images (been filed 
seperatly), the cpu performance in IE6 and moz are equivalant on my machine. 
Comment 56 Markus Hübner 2001-10-30 03:29:56 PST
Another testcase
just click on "company" to start the sliding menu.
The animation takes 1.5 secs on MSIE and 6.5 secs on the
latest mozilla build (2001102903) - using win2k SP2.

the dhtml code is at
Comment 57 Daniel Veditz [:dveditz] 2001-10-30 11:25:10 PST
What part of "tracking bug" do you guys not understand? Please file separate
bugs on each new problem, don't lard them all into this generic parent bug if
you want them to get seen and analyzed.

Since there are already a bagful of dependent bugs it'd also be nice to make
sure new examples aren't just more of the same.
Comment 58 Sivakiran Tummala 2001-10-30 11:34:12 PST
*** Bug 104593 has been marked as a duplicate of this bug. ***
Comment 59 Sivakiran Tummala 2001-10-30 11:36:30 PST is other example where the site is slow. 
Comment 60 Johnny Stenback (:jst, 2001-10-30 17:43:45 PST
Taking bug.
Comment 61 Johnny Stenback (:jst, 2001-10-30 17:45:12 PST
*** Bug 107634 has been marked as a duplicate of this bug. ***
Comment 62 Alan S. Jones 2001-11-27 18:12:48 PST
How is this bug marked Target Milestone .9.7 yet most of the bugs this depends 
on are marked 1.0 or future?
Comment 63 Johnny Stenback (:jst, 2001-11-27 19:40:53 PST
This is the tracking bug where most of the work on DHTML performance will be
done. We have to many DHTML performance bugs to start working on each and every
one individually, and most of them are due to the same few problems anyway.
Comment 64 Johnny Stenback (:jst, 2001-11-30 02:34:30 PST
*** Bug 100453 has been marked as a duplicate of this bug. ***
Comment 65 André Langhorst 2001-11-30 07:15:42 PST
URL from duplicate:

These applications are *VERY* slow, the guy uses DHTML for 3d and graphics
stuff. I think these are examples to measure DHTML speed in mozilla
Comment 66 Guru Meditation 2001-12-04 02:20:02 PST
André is right. MOZILLA'S DHTML is really slow.
I tested this URL with Mozilla under Windows 2000 (PIII-500Mhz & 128Mo)
IE 5.00         : Approximately 30 images peer second.
Mozilla 0.9.6   : Only one image every two seconds.
Mozilla-DHTML is 60 times slower than IE 5.
I do not know Mozilla's sources.
I know the language C.
I speak very badly English.
How may I help you?
(I use the systems: Windows, MacOS9, MacOSX and Linux)

Comment 67 Jeff Rouyer 2001-12-13 16:21:10 PST
Performance dependancies. This is a less than scientific observation, but it may 
help in focusing performance dependancies. I noticed that when the mozilla 
window (winxp platform) is 80-90% covered with another window say another 
browser window or a text editor, then any sort of intensive dhtml animation 
speed up considerably to what I consider to be its desired speed. Doing this 
test in other browsers (IE and NS4) has no real effect. cool eh? Useful info, I 
don't know, but I may be forced to develop pages that are 1 inch high.
Comment 68 Thorsten Gebuhr 2002-02-03 05:06:09 PST
I tried to test the performance of the latest nightlies with the "dynamic-core"
- tests.

They don't work any more with 2002020118. The CPU-usage goes up to 100% and
almost freezes the system, but the grafics are not shown correctly any more.

Also some other JavaSript/DOM/DHTML performance tests don't work correctly with
this nightlies.

Hope this is not showing up in 0.98..
Comment 69 WD 2002-02-03 07:59:03 PST
Latest 0.9.8 branch build 2002020206 also shows this hang
Comment 70 Markus Hübner 2002-02-03 08:17:14 PST
The issues you mentioned are described in bug 116252.
Unfortunately this and some other problems (bug 117061) will also
show up on 0.9.8

Comment 71 Sivakiran Tummala 2002-02-06 21:16:18 PST
*** Bug 124047 has been marked as a duplicate of this bug. ***
Comment 72 Johnny Stenback (:jst, 2002-02-13 17:47:04 PST
Pushing to mozilla1.0
Comment 73 Johnny Stenback (:jst, 2002-02-13 20:59:50 PST
*** Bug 107746 has been marked as a duplicate of this bug. ***
Comment 74 Fabian Guisset 2002-02-14 03:35:11 PST
*** Bug 98066 has been marked as a duplicate of this bug. ***
Comment 75 Fabian Guisset 2002-02-14 03:38:26 PST
*** Bug 98627 has been marked as a duplicate of this bug. ***
Comment 76 Fabian Guisset 2002-02-14 03:40:36 PST
*** Bug 110029 has been marked as a duplicate of this bug. ***
Comment 77 Fabian Guisset 2002-02-14 03:52:29 PST
*** Bug 77456 has been marked as a duplicate of this bug. ***
Comment 78 Fabian Guisset 2002-02-14 03:58:34 PST
*** Bug 78826 has been marked as a duplicate of this bug. ***
Comment 79 Daniel Bratell 2002-02-14 07:12:03 PST
Fabian, how can you make specific DHTML issues a duplicate of a tracking bug?
Each of these could be the instance of a specific problem that we could miss now
when the bugs are gone?
Comment 80 Fabian Guisset 2002-02-14 07:39:43 PST
Daniel, I know you have been profiling the DHTML perf bugs, but please see my
post in npm.dom for the explanation of the mass-duping.
Basically it is useless and a waste of time to investigate each and every single
dhtml perf bug we get, and it also spams us (who work on the DOM) to no end.
Once we address the main issues (too much style re-resolution, too much reflow,
and other stuff, which are already known), we will come back and check all the
dups and see whether they are fixed, and reopen them if needed. This is the only
reasonable solution we found to keep the DHTML perf bugs under control. 
Be assured that nothing will be lost. Important testcases and profiles will be
attached in a new tracking bug for the developers.

I also argue the fact that they are "specific DHTML issues", because all of
those I duped either didn't contain any information or lead us to the conclusion
that "we reflow too much". I would appreciate it if any further discussion
happened in the newsgroups.

And I apologize to everyone for the spam, but you get a little so that we get a
lot less ;-)
Comment 81 Nisheeth Ranjan 2002-03-13 17:55:07 PST
Pushing this tracking bug off my mozilla1.0 radar. The reflow coalsecing work in
bug 129115 will help (a lot) all the bugs that depend on this bug, and that's
all we'll be able to do for mozilla1.0.
Comment 82 Johnny Stenback (:jst, 2002-03-13 18:10:05 PST
Um, that was a comment from me, not from Nisheeth.
Comment 83 André Langhorst 2002-04-18 17:08:00 PDT
*** Bug 110246 has been marked as a duplicate of this bug. ***
Comment 84 Zibi Braniecki [:gandalf][:zibi] 2002-04-19 12:45:23 PDT
I have one question...

Few days ago, i downloaded Nightly build of Mozilla from mozilla's FTP ftom 

At now this address is down (why?).
That build ( i dont remember it's build id) had very, very fast DHTML. Really. 
I was shocked! Every DHTML page i checked worked very fast, all menus, 
animations... gosh..! :)

And today i downloaded Mozilla 1.0 RC1 and it has the same, old, very, very 
slow performance... I always check , and pages like this, where DHTML is a base.

I have no idea, why Mozilla 1.0 RC1 still has so slow performance and if there 
are chances to use DHTML parser from that nighlty relase???

And second question. I would like to use Mozilla, but i like DHTML, so i would 
like to use that nighlty build. Where can i find it???
Comment 85 André Langhorst 2002-04-19 14:24:13 PDT
just another updated URLs to view the pathetic speed of JS in mozilla (25-50
fold by roughly guessing), the ones I submitted before are 404

I just tried a current GMAKE build and it crashed randomly and refused to load
the above examples, but maybe I'm wrong and it's so fast that I can't watch the
animation anymore ;)
Comment 86 netscrape hater 2002-04-21 03:12:37 PDT
DHTML animation (moving layers)
DHTML Menus (hiding and showing layers)

The above two issues are triggered by an engine flaw and the inability
to redraw elements... especially on pages that contain background images
of any kind, and/or embedded images of more than 4-bit depth.

The browser's inability to handle the overflow property
Comment 87 David G King 2002-04-21 10:34:37 PDT
I just tried the first example from Comment #85. The page didn't finish loading,
well after a couple of minutes I gave up, but had to use CTRL-ALT-DEL to shut
down Mozilla as all Mozilla windows were unresponsive.

This on WIN98SE with a 500Mhz AMD using 1.0RC1. This really has to be fixed
before the final 1.0 release.
Comment 88 Julien Wajsberg 2002-04-22 04:38:24 PDT
Here (with Windows 2000), I was able to close only the faulty window (still
using Ctrl Alt Suppr though).
On older release, I had to close completely Mozilla (just like previous comment 87).
Comment 89 Zibi Braniecki [:gandalf][:zibi] 2002-04-23 13:05:28 PDT
Ok. Next tests.

Moving layers is about 100% faster in IE than Mozilla, during Opacity changes 
Mozilla works strange.

Didn't checked on Linux/Mac.
Comment 90 Thorsten Gebuhr 2002-04-24 09:51:40 PDT

interesting testcase.

But's good to see, that mozilla is faster than IE or at least has almost the
same performance in all the other tests here.
But I can verify your 100% underperformance in the moving of layers. Also I can
see the steps when IE is moving the layers and moz only shows the first and the
last step.

Interesting to see is also the repainting performance of the whole scene (after
all tests). When you're switching windows between mozilla and IE showing the
same scene - moz repaints it in no time and IE takes about 2 secs.

Best Regards
Comment 91 Zibi Braniecki [:gandalf][:zibi] 2002-04-24 12:58:50 PDT
Ya, Mozilla is faster, or equal to IE in most of tests (its very good. 
Improvment - in version 0.9.2 everything was such slow...)
My target was to show that only moving is such slow, not whole Mozilla :)

Th most interesting thing for me is that Mozilla slower moves complete layers 
(in first test) than cliped and opacited layers (last test), and IE inversely.

On my OS (win 2k, 392 ram,Matrox g400) during opacity changes every layer was 
repainted very slow with hiding it, delaying, and painting it one more with 
bigger opacity...

Thats second bug...
Comment 92 Garrett Smith 2002-04-25 05:37:33 PDT
Mac os x (10.1), G3/350, 256 mb ram.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417

I couldn't even make it through the first test (status bar updater) -- It took about
90 seconds just to get the operating system's attention to close the window!
Comment 93 Zibi Braniecki [:gandalf][:zibi] 2002-04-25 12:41:19 PDT
Garret, could You please tell me Your results in my tests? I'm very interested 
what with Mac.
Comment 94 Erik Arvidsson 2002-04-25 13:38:58 PDT
I don't know who got better speed in Mozilla than IE running the Alladyn test 
case. Mozilla is about 10 times slower than IE for the move case. (This is the 
case that needs to be fixed.) The tests for opacity were equally bad in both.

System: Windows XP, Pentium 3 800MHz, 386Mb

Internet Explorer 6.0:

Creating 200 layers - time - 641
Moving 200 layers 100 px to left - time - 4186
Cliping 200 layers - time - 160
Setting Opacity 10% - time - 15523
Reverting z-index for 200 layers - time - 140
Moving with changing opacity and clip - time - 30884

Latest nightly build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
rv:0.9.9+) Gecko/20020424)

Creating 200 layers - time - 941
Moving 200 layers 100 px to left - time - 38035
Cliping 200 layers - time - 120
Setting Opacity 10% - time - 25897
Reverting z-index for 200 layers - time - 131
Moving with changing opacity and clip - time - 30184
Comment 95 Zibi Braniecki [:gandalf][:zibi] 2002-04-26 17:07:12 PDT
Erik. Opacity problems are caused by DirectX 8.1 as i know... :/
With DirectX 7.x everything goes right.
Comment 96 Eric Rose 2002-04-27 00:28:25 PDT
DirextX 8.0 has the bugs with opacity..
Comment 97 Erik Arvidsson 2002-04-27 01:39:43 PDT
Interesting. I didn't know Mozilla used DirectX. Then I guess this is a 
windows only problem?
Comment 98 Zibi Braniecki [:gandalf][:zibi] 2002-04-27 03:31:41 PDT
Windows only. But not only DX8.0 - 8.1 too

But my tests should show other, bigger bug - moving performance

Comment 99 Ronald van Kuijk 2002-04-27 12:36:12 PDT
Try the experimental builds of bug #129115

these are my results on a 899 MHz laptop running linux with this 'experimental'

Creating 200 layers - time - 938
Moving 200 layers 100 px to left - time - 6363
Cliping 200 layers - time - 205
Setting Opacity 10% - time - 7923
Reverting z-index for 200 layers - time - 181
Moving with changing opacity and clip - time - 15961
Comment 100 Aaron Kaluszka 2002-04-27 13:23:03 PDT
We need a new experimental build with the patch for bug 102321 applied.
Comment 101 Zibi Braniecki [:gandalf][:zibi] 2002-04-28 02:28:34 PDT
Ronald. Hope it fix Windows problem too?
Your results are quite good. Not as good as IE6, but much better than todays 
Comment 102 Sören 'Chucker' Kuklau (gone) 2002-04-28 03:15:05 PDT
System: 500 MHz desktop running WinXP Pro with 416 MB RAM

					1)	2)	3)
Creating 200 layers			1072	1632-	1041+
Moving 200 layers 100 px to left	59696-	18727	8692+
Cliping 200 layers			290+	341	401-
Setting Opacity 10%			28050	40889-	21291+
Reverting z-index for 200 layers	201+	300-	290
Moving with changing opacity and clip	46928	68688-	37915+

1) Mozilla 2002-04-27
2) Mozilla 2002-04-22 with JS reflow patch
3) IE 6

+ marks best, - marks worst. Since the build without the patch is in some cases
faster than the build with it, it seems like we need an updated experimental build.
Comment 103 Ronald van Kuijk 2002-04-28 10:13:12 PDT
I have to agree with chuck. I did some tests as wel on winXP (1GHz/128MB laptop)
with the following results.

I did a test on another laptop (1GHz/128MB winXP) with the following results.

				        1)       2)     3)
Creating 200 layers			410+     591    501
Moving 200 layers 100 px to left	26138    5638   2964+
Cliping 200 layers			100+     151    190
Setting Opacity 10%			9914+    13780  14090
Reverting z-index for 200 layers	100+     140    240
Moving with changing opacity and clip	15442+   21801  16404

1) Mozilla 2002-04-28
2) Mozilla 2002-04-22 with JS reflow patch
3) IE 6

So I have to agree with you that there should be a new experimantal build....
that would give us a 'win' on all but one point and even on that point we are
down from 10x slower to only 2 times slower...

So... we are getting there...
Comment 104 Robert Kaiser 2002-04-28 11:26:36 PDT
We had 2%-6% performance win on variuos tinderbox performance tests since 22nd
due to several fixes, e.g. a significant getElementById() speedup from bug
118933 and a significant sppedup for amny JS objects from bug 139243, and that's
all fixes on the JS/DOM side, so very likely to affect DHTML, and that should be
the reason for newer builds being faster than that test build...
Comment 105 Zibi Braniecki [:gandalf][:zibi] 2002-04-28 13:17:41 PDT
Ok. I added two points to my test. (
Inputing HTML and resizing layers.

I found pretty nice bug in IE6 (after resize, try to scroll window to bottom) 
and some weird bug in Mozilla - Mozilla just hanged for me after inputing text. 
(Win2K/392 ram). Can anyone reproduce it?
Comment 106 Chris Casciano 2002-04-28 14:03:40 PDT
I tried to run the alladyn tests on OS X, but I'm not sure I trust the numbers
its giving me. Specifically, the numbers seem to skew when the browser hangs
with the spinning rainbow/working cursor. The final test (resize) is the worse
in that the browser was hung for over 2 minutes (eyeballing an external clock)
and both times the number that was reported back was <1000. [The golfers on my
TV were moving faster]. Also, on none of the tests in moz or chimera did I see
any animating actually happening - only the the end results were actually painted.

Powerbook G4/400mhz/OS X 10.1.4/1GB ram

	RC1	Trunk*	Chimera	0.2.5	IE5.1.4
Test 1	2121	1509	1520		1239
Test 2	36442	17694	27431		9698
Test 3	349	298	304		134
Test 4	16031	13892	12740		3063**
Test 5	358	307	288		158
Test 6	32172	27940	26333		14590**
Test 7	841	626	544		hung
Test 8	813	646	hung (8+min)

* Trunk build was: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.0+)
** These numbers may not be of much use in a comparison as IE/Mac doesn't
support opacities
Comment 107 Chris Casciano 2002-04-28 14:07:45 PDT
Um looking over my numbers there was one typo - the test 2/trunk build numbers
were 37694 and not 17694.
Comment 108 Nicolas Combelles 2002-04-28 17:21:11 PDT
Moz RC1 / IE5.5   on Win2K/Athlon750/ram=392Mo

Creating 200 layers = 641	/460
Moving 200 layers   = 21410	/2774
Cliping 200 layers  = 120	/150
Setting Opacity 10% = 8112	/15622
Reverting z-index   = 120	/120
Movingchangopacclip = 11927	/25006
Inputing text 	    = 330	/271
Resizing 200 layers = 230	/241

Moz has best results with opacity, but notice layers become unvisible until it 
reaches 10%.

IE55: No bug after resize.

I'm impressed by Moz here. But it still move slowly ..  And here again, they do 
not move until they jump to final destination. That is not an animation.
Comment 109 Vadim Berezniker 2002-04-28 18:10:07 PDT
Somebody should try the tests after applying patch in bug 129115
Comment 110 Ronald van Kuijk 2002-04-29 09:06:26 PDT
We're trying to keep the statistics of the aladyn tests in bug #140789 just to
prevent the meta bug from getting filled with this info.

For an enourmous increase in 'moving' speed, try the experimental build of
mozilla (look in 

They are not merged with the recent trunk, so other figures are worse, but the
moving speed increases by 450% (no kidding!!!!)
Comment 111 Sören 'Chucker' Kuklau (gone) 2002-04-29 09:40:22 PDT
> They are not merged with the recent trunk, so other figures are worse, but the
moving speed increases by 450% (no kidding!!!!)

Well for me it's "only" 297%, but that's still quite good.

See my results at <>.
Comment 112 Zibi Braniecki [:gandalf][:zibi] 2002-04-29 10:08:51 PDT
For me change is from 25 sec in moving test to 10 sec. It's still very 
important change!!!
Comment 113 Julien Wajsberg 2002-05-01 09:27:19 PDT
I just tried the scripts in with
the most recent build (2002043010 trunk)

It seems a real effort has been done; indeed, all the scripts load and work
(although very slower than with IE), whereas in less recent post-RC1 builds all
except the duplex script didn't even load.

I saw however a regression : the duplex script used to work very smoothly in
recent builds, and in this one it isn't. Maybe because it isn't an optimized
build, I don't know ?
Comment 114 WD 2002-05-05 10:41:50 PDT
I agree with comment #106
I'm not sure if these numbers are all accurate at .   For example, the last
test with resizing 200 layers.    The test tells me the result is "90" which
should be about instantaneous, while my watch tells me the result is about 15
Comment 115 Zibi Braniecki [:gandalf][:zibi] 2002-05-05 11:52:11 PDT
WD: check source code. At all i made all i could to show true values. I see the 
same bug. For me it's delay between end of parsing and end of doing changes 
(redrawing and following code).
At all, in every test, timeA is set line before statment, and counted line 
after. There shouldnt be any issues like this, but it happens. It can be 
related to setTimeout bug, or sth other. Boris should explain this... i hope :)
Comment 116 Mathew McBride 2002-06-08 21:35:50 PDT
Keep as *new*. Please define alternative location for bug page. 
I use: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020608
(SeaMonkey Build)
Comment 117 Jacob Kjome 2002-06-08 23:20:52 PDT
Created attachment 86987 [details]
Original file referenced from URL field all this time

Well, it took a while, but I'm finally getting around to posting the test
referenced by URL filed for this bug which has been defunct for a couple years
now.  Better late than never, I guess.

Comment 118 Jacob Kjome 2002-06-08 23:23:51 PDT
removing defunct URL from URL field.

Comment 119 Zibi Braniecki [:gandalf][:zibi] 2002-06-15 02:08:48 PDT
I think we can change Target to anything more realistic than past. JS is still
slow. Slower than in past trunks. Main problem for me are:

1) Opacity speed. It's very, very slow (Windows). (link: )
2) At all big problems with moving/cliping and working with big GIF/JPG in Layer
(only on Windows). (link: ; ) - compare CPU use, mouse
freezing and animation speed on IE and Mozilla.
3) Problems with Opacity's properities. Setting 0.1 hangs Opacity and such...

Who can add his list?
Comment 120 Zibi Braniecki [:gandalf][:zibi] 2002-06-15 02:16:01 PDT
I forgot to add link to 3) point - bug #144832
Comment 121 Eddie Traversa 2002-06-15 02:30:14 PDT
actually its the % value in the opacity script that throwing moz out. For some 
reason, moz no longer likes that value, but if you gear the script to not use 
% then moz opacity actually rocks.

Clipping I find is being caused by which direction you clip, if you clip from 
left to right or right to left, then moz is reasonable, but if you clip from 
top to bottom or bottom to top then moz performance degrades.  You may want to 
verify this and see if you get similar results. 
Comment 122 Zibi Braniecki [:gandalf][:zibi] 2002-06-15 02:44:10 PDT
Not only. Please, read carefully bug #144832 there are more 3 or 4 issues with
useing '%', using float, and changing between both.
Comment 123 Tomasz Krysinski 2002-06-20 06:03:18 PDT
Created attachment 88465 [details]
A testcase for resizing of the document body

I'm sure you already know about bad performance with resizing of the document
body, so you'll just have a simple testcase.

Same thing happens when the content is embedded in an iframe.
Comment 124 Markus Hübner 2002-06-20 06:06:45 PDT
This is a TRACKING BUG - please comment about specific problems in the 
relating bug(s).
Comment 125 Zibi Braniecki [:gandalf][:zibi] 2002-06-20 13:19:55 PDT
Markus: i think that we should change description. At now it's an 'umbrella' bug
instead of the tracking one.
Most of DHTML performance bugs were marked as DUPLICATE for this bug, so we
write about specific problems here. My testcase is more global and show specific
parts of whole 'performance'.
Comment 126 Adam D. Moss 2002-06-20 13:26:22 PDT
'Umbrella' bugs are tough to handle: tough for a single
engineer to conclusively fix and tough to verify.  That's why
we use the paradigm of tracking bugs and specific bugs.
Divide and conquer.

Good testcases are welcome, but please do file a specific
bug for a specific problem and add a dep to the tracking
bug (or nominate that the assignee look into doing so).

Comment 127 Zibi Braniecki [:gandalf][:zibi] 2002-06-20 13:38:23 PDT
Sure... i made. Five or six.. all of them are DUPE of this bug. Thats why i'm
talking here about them.
Comment 129 Zibi Braniecki [:gandalf][:zibi] 2002-07-12 23:37:21 PDT
During last weeks following trunks shows a regression in DHTML performance. I
cannot belive in actual Target Milestone for this bug.
Comment 130 Mathew McBride 2002-07-13 17:12:12 PDT
ALL Horribly slow in Mozilla 1.1a+
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a+) Gecko/20020713.
Faster in IE. 
Mozilla not showing background on blobs.
Debug ==> Viewer Demos ==> DHTML having problems resizing screen when objects
move. Saved file and done the same in IE. IE didn't care if the objects hit the
wall or not, just kept expaning the space.

I still can't belive that it's been 3 years since this bugs been reported, and
it hasn't been resolved.

> Mozilla 1.1 is faster than Mozilla 1.0.

>Unfortunately IE remains really fastest :-(
At least back in 1998, the Mozilla project was reset around a new layout engine,
instead "of slapping our heads against the old one too long". Shows how good
open source can be. (I.E may be faster, because it loads the page using whats
there. In Mozilla and even Netsape 4.77, it waits for stuff to be fully
downloaded. It has something to do with TCP/IP enginnering).
Comment 131 Markus Hübner 2002-07-14 04:53:12 PDT
Mathew - the behaviour you mention is bug 155160
ya, unfortunately there have been some regressions lately causing some 
problems. it's painting, event handling and handling (interrruptable) reflows.
I do hope that a focus on DHTML (perf) will be set for Mozilla 1.1 / 1.2 
Comment 132 Zibi Braniecki [:gandalf][:zibi] 2002-07-14 05:37:24 PDT
Marcus, bigger problem than regressions since 0.9.7 is that we can clearly see
regresions since 1.0RC3!!!
Some often used features of JS are impossible to use for Mozilla.
For example moving layers. We HAVE progression, but it's still to slow. Much to
slow in compare with IE,NS4,Opera(!!!). Or Drag&Drop. Mozilla users cannot use
Drag&Drop feature as normal part of UI. The same with Real Time animations where
we  have to check position of every moving layer in each step. I created few
testcases for separated issues, at now i only want to remind about this problem.

It's really big problem. It is long past the age of WebDocuments. Todays we're
creating applications with extremly extended interface. And most of this is done
by JavaScript -> DHTML. In Mozilla this problem is pass over in silence since
may. At now Mozilla 1.0 is out, we have beta of Moz1.1 and problem still exists
and it's very, very huge.
Comment 133 shelby 2002-07-14 08:02:31 PDT
Bottom line is that the Netscape engineers better formulate a memo to Steve 
Case and tell him that if he serious about producing a browser, then he better 
increase his investment in Mozilla development by several tens of $millions per 
year.  Microsoft had *ORDERS* of magnitude more *PAID* man hours in IE in the 
last several years.

Bottom line is that everyone I know is giving up on Netscape.  For example, 
from 092, they broke the drop-down menu at, which worked in 
091 and works in IE.  I reported the bug but so far lately I do not feel much 
motivation to try to find a fix, because I think Mozilla will likely break it 
again.  My partners such as, have started to de-prioritize NS6 
compatibility.  It simply is not worth the effort, especially when work is 
obliterated in later versions.

Open source is a failed concept.  It only works where the creators are able to 
produce a very successful saleable product based off the open source project, 
e.g. PHP and mySQL.  Also those work because the scope of the projects are 
within the resources of a fairly tight core open source development group.  The 
problem with Mozilla seems to be that it is too ambitious and the core 
development group is vastly understaffed.  There may be a lot of people 
interested in reporting bugs, but not enough capable of fixing them.  I 
consider myself a very accomplished programmer, and I have been able to go into 
PHP source and makes important changes within a few hours.  I have tried to 
look at the Mozilla source and it is so huge and complex, and also the portions 
I looked at were not well object-oriented (in order to faciliate quick 
learning), or at least there was a lack of code documentation.

Bottom line is that people in the USA have lost 50% of the wealth recently in 
stock market.  They are focusing in on core activities, such as family, buying 
land, and earning income.  All this noise on a browser which no one wants to 
invest real $ in, and which is continually oscillating without clear and 
decisive movement forward, is being progressively ignored by people.

I am thinking about removing my email address from all the bug lists at 
Mozilla, unless I see the core Netscape engineers produce a memo as a blunt 
wakeup call to Steve Case.

Shelby Moore
CEO 3Dize, Inc. (
CEO, Inc.

sole programmer of Cool Page* (1998), Art-O-Matic* (1996), WordUp* (1986), 
TurboJet (1988)
contributing programmer to* (2001), Corel Painter* (1993 - 5), 
Corel ArtDabbler, EOS PhotoModeler (1996), FONTZ! (1988)

* denotes major involvement in massive multi-year R&D projects with millions of 
characters (1000s of pages) of code
Comment 134 Stig Nygaard 2002-07-14 08:12:27 PDT
I don't think this is the right place for this discussion, but just a quick
remark on comment #133:

> It simply is not worth the effort, especially when
> work is obliterated in later versions.

The idea with the Mozilla 1.0 release is exactly to give you a stable platform
to develop to. From now on backwards compatibility should be mostly guaranteed.
Previous milestone releases (which Netscape 6.x is build upon) didn't have this
Comment 135 David G King 2002-07-14 08:25:43 PDT
I agree, Comment #133 doesn't belong here, however I too have to respond based
on recent developments.

I work for a US State Department as a Senior Analyst, and we just received some
reponses to an RFP for somw web development. One company stated that they do not
support any Netscape browser above 4.x due to incompatabilities with that
companies web code. The problem with this is that this web site we are working
to develop will be used by thousands of people (including multi-national corps,
banks, accountants, tax preparers, etc) to pay millions of dollars of taxes due.

In other words, we may be forced to put a notice on our web site saying IE only
(as you know that state departments are forced by the taxpayers to accept the
lowest bid).
Comment 136 Zibi Braniecki [:gandalf][:zibi] 2002-07-14 08:29:46 PDT
I think that comment #133 is a mistake, it has nothing (or alomst nothing) to
main subject of bug, or even to my last comment.

I'm also afraid that following comments will be related to comment #133 and main
problem which for shure is DHTML performance and Mozilla plan for fixing it
('dhtml performance' is a huge part of many issues which gives blodly bad
result), can be forgotten.

I also want to react for comment #133. Open Source in Mozilla was one of the
greates ideas i ever heard about. Thanks to this method, profesionalism of
authors and many, many years allday work, we have first browser which has chance
to be compared to IE. Dont try to make me lauging, and dont tell me about Opera
or such. Opera is a mistake, not a Browser. If i wanted to focus a DHTML problem
and spent some time to write my post, it was only for one reason - to help
building Mozilla. I and many of my friends strongly belive that Mozilla is a
futur. Compare speed of progrssion in Mozilla and IE. When You'll see anything
new in IE? In January? Meaby. Open Source gives Mozilla more power than we can
see now. In futur years, in futur years there will be built new broweser based
on Mozilla, all security holes will be finded much faster than in IE and it's at
now better in many parts.

Talking about DHTML performance which is my biggest problem with Mozilla right
now (due to my job which is connected with DHTML) i'm fully enjoyed in this
project and i want to give my full support to drivers.
Comment 137 shelby 2002-07-14 10:50:27 PDT
I want this bug and the other thousands of bugs to get fixed also.  That was 
the whole point of making my previous post.  That is why I said that they ONLY 
way it is going to happen is if AOL gets serious about investing in this 

The non-realist will say that my post is inappropriate.

I am sad for those people who invested significant portions of their lives in 
this project.  I have also invested probably close to $10,000+ trying to track 
and support NS6+.  I'd rather cut my losses now, unless I see a significant 
increase in the $ being invested.

Go ahead and attack my opinion, but the bottom line is still the bottom line.

Comment 138 Nicolas Combelles 2002-07-14 11:25:25 PDT
---- Shelby : ------
Support it or not but do not debate it here.
-> Bugs won't be fixed sudendly with $$ (it is known that more developper add 
complexity and does not make things go faster). But off course $$ are welcome 
and there is enough task for more people. No debate on AOL strategy .. this is 
a time loss.

-> Your personnal pb : 3 solutions : 1- Just leave moz support for now. 2- Base 
your dev on Moz 1.0 (comment #134).  3 - Wait for a commercial final version 
(NS7 or AOL8) to base your dev on.  (I go for 2 waiting for 3).

Mm.. look like there is a market for compatiblity ... :D .

Now please do not talk about this here anymore (answer me there if you really 
want : too much CC's annoyed (including me), this is not a 

I hope this bug will be fixed before NS7 get released .. good luck, good work.

Nicolas Combelles -
Comment 139 Stig Nygaard 2002-07-25 12:14:34 PDT
On my PC (AMD K6-II/400MHz, Win98) Mozilla 1.1beta completely freezes when
entering the solar system animation at It was the same problem in
1.0RC2, but it was solved in RC3 and the final Mozilla 1.0 release. Now its back
:-( I have to kill the browser from the task-list.
Comment 140 rob cherny 2002-07-25 12:31:22 PDT

I'm noticing and asking around on the .perf newsgroup if anyone else is 
noticing a slow down on this page.  NS6 and Moz 1.0 fine, 1.1b is choppy and 

Speaking specifically of the sliding action from the lower left (boxes).

Anyone see the same thing or is it just me?


Comment 141 André Langhorst 2002-07-25 16:23:42 PDT
tested on 2002072514, wXP
I don't know if this one is already covered by one the endless bugs...

2) Move the blue-like box on the right to somewhere in the center of the page
3) Drag'Resize the blue box (bottom-left corner), experiment a bit with it,
slower, faster > anyway you'll notice that it's crappy slow (1800+XP + 1GB RAM)
as opposed to IE6, where it just seems to be limimted by the speed of my movements

Then again moving the box is terribly slow, if it is very small it does not move
at all until you slow down a lot...
Comment 142 José Jeria 2002-08-04 08:31:17 PDT
The dynamic-core scripts are back at:
Comment 143 Thorsten Gebuhr 2002-08-16 03:02:16 PDT
The solar-system mentioned in #139 is working again in moz 1.1RC (2002081419).
And it's fast enough to use it - even on my slow PC (AMD K6-III 450).

But I think there is a performance decrease compared to former releases in the
dynamic-core tests (esp. the blobs).
Comment 144 IU 2002-08-16 07:11:06 PDT
Regarding that solar system animation, check out the CPU utilization - it's 
maxed at 100 %.  For comparison, IE 6.0 uses 0 - 1 % CPU!!!

Mozilla 1.1 Build ID: 2002081419 on Windows 2000 Server, SP3; 512 MB RAM

Mozilla is improving; however, the whole CPU utilization issue, when dealing 
with dynamic content - especially GIF animation, needs a lot of work, as it's 
the root of many of Mozilla's performance woes.
Comment 145 rob cherny 2002-08-28 12:53:27 PDT
Ok, sorry if this is the wrong place for this (on one of the "depends on"
bugs?), but another site with some 100% CPU spikes on clipping and the like ...

Screaming fast in IE.  Slower than crazy in Mozilla. Basically unusable.

It's youngpup's ( ThreeOh scroller -- I think it may have to do
with the volume of content being scrolled.

Comment 146 Bob Sinclar 2002-10-25 14:29:23 PDT
There are still regrettably big differences of performance between Mozilla and
Please,look at this DHTML animation on IE6, then on Mozilla:
The IE6's speed is incredible!
Comment 147 IU 2002-11-18 16:14:39 PST
Also Mozilla uses 100% CPU rendering the rising bubbles at  Although IE also does a somewhat piss-poor job on the page, it is faster than Mozilla.  All versions of Mozilla up to and including 1.3a+ Build ID: 2002111808 are affected. 
Comment 148 Johnny Stenback (:jst, 2003-03-23 13:29:42 PST
Mass-reassigning bugs to
Comment 149 u88484 2005-02-14 17:32:06 PST
just cleaning up bugs that have been resolved in some way, be it
fixed/invalid/WFM or whatever
Comment 150 Daniel Veditz [:dveditz] 2005-02-14 18:46:45 PST
Please don't make changes to bug state if it's not your bug. Especially for such
a massive cleanup discuss it first. We leave fixed bugs on these lists for
historical tracking (and in case they're reopened); it's easy enough to hide
them in the dependency tree view.
Comment 151 Carlo Alberto Ferraris 2007-01-11 08:03:14 PST
Just a little up to remember that this is still a issue:
if you take a look at the demos in the gallery section of (e.g. 1, 2, 3, 15) where a lot of images are moved and resized on the page you'll notice that the performance of Fx is ridiculous compared to IE (version 7, in my case).

This happens on both 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070110 Minefield/3.0a2pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv: Gecko/20061204 Firefox/

p.s: specs of my box: athlon64 3200, 1024MB DDR533, radeon 8500.
Comment 152 John A. Bilicki III 2010-09-04 17:09:00 PDT
Created attachment 472213 [details]
DHTML Width Animation

This bug is valid, this file animates quickly in Opera and slow in IE9, Firefox 4 Beta 4, and Safari 5. Adjusting the setTimeout makes Opera clearly animate at different speeds.
Comment 153 Ryan VanderMeulen [:RyanVM] 2010-09-05 05:41:17 PDT
John, this bug is a tracking bug. Please file a new bug that blocks this one and post your testcase to that one.
Comment 154 Worcester12345 2016-07-08 09:22:49 PDT
(In reply to John A. Bilicki III from comment #152)
> Created attachment 472213 [details]
> DHTML Width Animation
> This bug is valid, this file animates quickly in Opera and slow in IE9,
> Firefox 4 Beta 4, and Safari 5. Adjusting the setTimeout makes Opera clearly
> animate at different speeds.

Have you tried in a recent version of Firefox? If so, report results.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #153)
> John, this bug is a tracking bug. Please file a new bug that blocks this one
> and post your testcase to that one.

Did a new bug ever get opened?

Note You need to log in before you can comment on or make changes to this bug.