from the layout newsgroup:
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:
http://timb.simplenet.com/dom/ (these demos include ending of
document.write("/script") where it should be
document.write("\/script") to escape the end script, but that is
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!
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
Is this a dup of 12761?
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 (
http://18.104.22.168/w3CDomtest.html ). 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.
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: http://22.214.171.124/w3CDomtest.html
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
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.
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
Clearing WORKSFORME resolution due to reopen.
The performance issues here may be similar to the ones for bug 12761.
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.
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.)
Did you really mean 32378?
No, I'm a moron: 38378.
I'm still keeping this open as a tracking bug for animation performance work
that I hope will happen for nsbeta3.
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?
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
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.
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?
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?
If you compare http://www.cantir.com/meninas/parallax.html on NS4.x and Mozilla,
I think some work still has to be done..
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.
Our DHTML test #13 hangs my linux build; takes several seconds to respond to UI
events. Marking All/All.
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..
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.
mozilla renders the www.sony.com homepage slowly compared to IE5.x on windows 2000
adding the keyword top100 as sony is one of the top100 sites.
adding myself to cc list
http://www.threeoh.com and http://www.kiiroi.nu are among the top 10 sites in
the (web)design community.
The DHTML performance of the news-scrollers are terrible, causing major
I've just look closer at the fantastic IEemu series at http://webfx.nu (thanks
to Mozilla for to be able to do this!) and found out something interesting.
Sorry if it's already known.
GenericMove (http://webfx.nu/dhtml/ieemu/genmove.ieemu.html) works awsome.
GenericResize (http://webfx.nu/dhtml/genresize/genresize.html) 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
didn't look at the code but I uses similar somewhere and it's based on "clip"
Hope this helps.
another sites with bad 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. http://www.rouyerdesign.com
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
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..
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.
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.
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.
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
http://www.mozilla.org/performance/tools.html 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.)
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.
re: the overflow: thing.
I wrote the scroller at threeoh.com, and have spent a great amount of time
writing dhtml in general - for mozilla as well as IE and the other dhtml-
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 http://www.youngpup.net/z_dropbox/moz_perftest/ --
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 younpup.net 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.
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.
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
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.)
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 mozilla.org? 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.
Sorry for the rant! This issue is very meaningful to me as it is to a number
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..
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.
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??
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.
IE 5.0 SP1
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.
confirming the same as jo jo - using a PentiumIII 600MHZ, 327RAM, using MSIE6.0
and build 2001102403 on win2k with SP2.
To flame Brendan ;), XHTML is not just a future thing:
"All of our development work for the new MSN.com 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.
"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
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.
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.
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?
The animated menu example isnt a bug, rather an oversight on my behalf in not
browser sniffing for mozilla. Got it working now.
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%.
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
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.
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
No timer, loops through an array and shows / hides layers on user mouse events.
Performance significantly worse than moz.
Uses timers set at 50 and 45 respectively, clipping animation technique used,
increments and decrements clipping region of layers 10 pixels at a time
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?
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.
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
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.
*** Bug 104593 has been marked as a duplicate of this bug. ***
http://www.sony.com is other example where the site is slow.
*** Bug 107634 has been marked as a duplicate of this bug. ***
How is this bug marked Target Milestone .9.7 yet most of the bugs this depends
on are marked 1.0 or future?
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.
*** Bug 100453 has been marked as a duplicate of this bug. ***
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
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)
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.
I tried to test the performance of the latest nightlies with the "dynamic-core"
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
Hope this is not showing up in 0.98..
Latest 0.9.8 branch build 2002020206 also shows this hang
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
*** Bug 124047 has been marked as a duplicate of this bug. ***
Pushing to mozilla1.0
*** Bug 107746 has been marked as a duplicate of this bug. ***
*** Bug 98066 has been marked as a duplicate of this bug. ***
*** Bug 98627 has been marked as a duplicate of this bug. ***
*** Bug 110029 has been marked as a duplicate of this bug. ***
*** Bug 77456 has been marked as a duplicate of this bug. ***
*** Bug 78826 has been marked as a duplicate of this bug. ***
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?
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 ;-)
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.
Um, that was a comment from me, not from Nisheeth.
*** Bug 110246 has been marked as a duplicate of this bug. ***
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 http://alladyn.art.pl ,
http://dhtmlcentral.com 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???
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 ;)
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
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.
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).
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.
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
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.
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
Thats second bug...
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!
Garret, could You please tell me Your results in my tests? I'm very interested
what with Mac.
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;
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
Erik. Opacity problems are caused by DirectX 8.1 as i know... :/
With DirectX 7.x everything goes right.
DirextX 8.0 has the bugs with opacity..
Interesting. I didn't know Mozilla used DirectX. Then I guess this is a
windows only problem?
Windows only. But not only DX8.0 - 8.1 too
But my tests should show other, bigger bug - moving performance
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
We need a new experimental build with the patch for bug 102321 applied.
Ronald. Hope it fix Windows problem too?
Your results are quite good. Not as good as IE6, but much better than todays
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.
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...
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...
Ok. I added two points to my test. (http://alladyn.art.pl/gandalf/MozillaTests
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?
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
Um looking over my numbers there was one typo - the test 2/trunk build numbers
were 37694 and not 17694.
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
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.
Somebody should try the tests after applying patch in bug 129115
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!!!!)
> 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 <http://soeren.mystfans.com/mozilla/dhtml-perf.html>.
For me change is from 25 sec in moving test to 10 sec. It's still very
I just tried the scripts in http://www.dynamic-core.net/scripts/index.php 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 ?
I agree with comment #106
I'm not sure if these numbers are all accurate at
http://alladyn.art.pl/gandalf/MozillaTests/dynl.html . 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
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 :)
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
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.
removing defunct URL from URL field.
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: http://126.96.36.199/gandalf/bolcz/ ;
http://188.8.131.52/gandalf/bolcz/index2.html ) - 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?
I forgot to add link to 3) point - bug #144832
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.
Not only. Please, read carefully bug #144832 there are more 3 or 4 issues with
useing '%', using float, and changing between both.
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.
This is a TRACKING BUG - please comment about specific problems in the
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'.
'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).
Sure... i made. Five or six.. all of them are DUPE of this bug. Thats why i'm
talking here about them.
DHTML to test the performances of Mozilla.
The site http://www.dynamic-core.net/ is not available.
But demos DHTML are directly accessible to the following addresses:
Mozilla 1.1 is faster than Mozilla 1.0.
Unfortunately IE remains really fastest :-(
Please , compare Blobs's speed on Mozilla 1.1, then then on IE.
During last weeks following trunks shows a regression in DHTML performance. I
cannot belive in actual Target Milestone for this bug.
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).
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
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
may. At now Mozilla 1.0 is out, we have beta of Moz1.1 and problem still exists
and it's very, very huge.
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 DownloadFAST.com, 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 DSEffects.com, 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.
CEO 3Dize, Inc. (CoolPage.com)
CEO DownloadFAST.com, Inc.
sole programmer of Cool Page* (1998), Art-O-Matic* (1996), WordUp* (1986),
contributing programmer to DownloadFAST.com* (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
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
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
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.
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.
---- 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 : email@example.com) 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 - www.udhtml.com
On my PC (AMD K6-II/400MHz, Win98) Mozilla 1.1beta completely freezes when
entering the solar system animation at
http://www.cross-browser.com/ss/solar_system.html. 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.
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?
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...
The dynamic-core scripts are back at:
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).
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.
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 (www.youngpup.net) ThreeOh scroller -- I think it may have to do
with the volume of content being scrolled.
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!
Also Mozilla uses 100% CPU rendering the rising bubbles at http://www.nonags.com/. 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.
Mass-reassigning bugs to firstname.lastname@example.org
just cleaning up bugs that have been resolved in some way, be it
fixed/invalid/WFM or whatever
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.
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 http://www.dhteumeuleu.com/ (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:184.108.40.206) Gecko/20061204 Firefox/220.127.116.11
p.s: specs of my box: athlon64 3200, 1024MB DDR533, radeon 8500.
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.
John, this bug is a tracking bug. Please file a new bug that blocks this one and post your testcase to that one.
(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?
After i updated my Firefox browser i've had big problems useing http://www.tvtvtv.dk Can it be the same kind of bug?
(In reply to Peter Larsen from comment #156)
> After i updated my Firefox browser i've had big problems useing
> http://www.tvtvtv.dk Can it be the same kind of bug?
Please file a new bug on whatever you are having problems with, with more details. ("I've had big problems using site XXX" doesn't tell us anything useful in reproducing it or tracking down why, especially for a main domain with lots of pages within it and options to choose. It's very unlikely that it's due to DHTML performance.
(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.
setTimeout(self, 1) is not a smart way to do smooth animations, so that's not really a valid test.