Closed Bug 21762 Opened 25 years ago Closed 3 years ago

[meta] tracking: poor performance using DHTML

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: buster, Unassigned)

References

(Depends on 5 open bugs,
URL
)

Details

(4 keywords)

Attachments

(3 files)

Original file referenced from URL field all this time
4.80 KB, text/html
Details
A testcase for resizing of the document body
950 bytes, text/html
Details
DHTML Width Animation
1.57 KB, application/xhtml+xml
Details 
from the layout newsgroup:

Subject:
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:

http://206.9.170.23/w3CDomtest.html


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
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!

thanks

Jake
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Summary: poor performance using DHTML → poor performance using DHTML
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
WORKSFORME.
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://206.9.170.23/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.

Jake
Status: RESOLVED → REOPENED
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://206.9.170.23/w3CDomtest.html

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.
Status: REOPENED → ASSIGNED
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.
Resolution: WORKSFORME → ---
Clearing WORKSFORME resolution due to reopen.
The performance issues here may be similar to the ones for bug 12761.
Summary: poor performance using DHTML → [PERF] poor performance using DHTML
Marking [PERF].
Keywords: perf
Summary: [PERF] poor performance using DHTML → poor performance using DHTML
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.
Summary: poor performance using DHTML → tracking: poor performance using DHTML
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.)
Depends on: 21879, 32378
Did you really mean 32378?
No, I'm a moron: 38378.
Depends on: 38378
No longer depends on: 32378
I'm still keeping this open as a tracking bug for animation performance work 
that I hope will happen for nsbeta3.
Keywords: nsbeta3
Target Milestone: --- → M18
We're having problems with DHTML animations at:

http://www.levelred.com/index.html

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
bugs.
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.
Whiteboard: [nsbeta3-]
Target Milestone: M18 → Future
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?
Keywords: dom0
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?
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
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

 http://www.dynamic-core.net/widgetx/index.htm

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

Still I think mozilla is a great product.
Depends on: 40988
Depends on: 12761, 64516, 70156
Depends on: 66881, 70100, 78103
Our DHTML test #13 hangs my linux build; takes several seconds to respond to UI
events. Marking All/All.
OS: Windows NT → All
Hardware: PC → All
Depends on: 65509, 82924
Depends on: 83088
Depends on: 84891
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..
Depends on: 83852
Depends on: 87808
Depends on: 95072
Depends on: 97287
Keywords: meta
Depends on: 98066
Depends on: 98627
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.
Depends on: 98828
Depends on: 95007
Blocks: 71668
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.
Keywords: top100
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 
inconveniences.
Keywords: nsCatFood
Depends on: 75121
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
champion.

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.
another sites with bad performance:
http://boomtown.net
http://bigbrother.dk
http://musik.dk
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. 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 

http://dhtmlnirvana.com/ 

Eddie Traversa
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.
No longer depends on: 66881, 78103, 83852, 95072
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:

\/\/hatever.

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
faster.
(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. 
 
http://dhtmlnirvana.com/moz/mozlinear.htm

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 
NS4. 
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 
significantly.

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-
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 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.

thanks

Aaron Boodman
www.youngpup.net
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
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.)
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.

/be
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..




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 
you...
http://www.projectseven.com/mozbug/

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

http://dhtmlnirvana.com/moz/flower1.htm

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. 

http://dhtmlnirvana.com/moz/flower2.htm

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
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
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
IE6

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.
See http://news.cnet.com/news/0-1005-200-7655334.html

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.
Depends on: 106796
"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
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 

http://www.dhtmlnirvana.com/mike/test/pop_test.htm

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%.

http://www.fordwebs.com/test/newfordwebs/index.asp

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

http://www.dhtmlnirvana.com/mike/test/pop_test1.htm  

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? 




Just to add further, 

There is an animated menu example here that uses images 
http://www.dhtmlnirvana.com/mike/test/pop_test.htm  

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

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.
Blocks: 103712
Another testcase
http://www.world-direct.com/mozilla/dhtml/index.html
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
http://www.world-direct.com/mozilla/dhtml/slidingmenu.js
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.
Depends on: 107634
Taking bug.
Assignee: vidur → jst
Status: ASSIGNED → NEW
Priority: P3 → P2
Target Milestone: Future → mozilla0.9.7
*** Bug 107634 has been marked as a duplicate of this bug. ***
Depends on: 107746
Depends on: 109425
Depends on: 110029
Depends on: 110246
Depends on: 78826
Depends on: 97938
Depends on: 87165
Depends on: 93766
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:
http://www.dynamic-core.net/widgetx/

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)
http://www.dynamic-core.net/widgetx/examples/blobs.htm
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)
Depends on: 74826
Target Milestone: mozilla0.9.7 → mozilla0.9.8
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.
Depends on: 117061
No longer depends on: 109425
Depends on: 117436
Depends on: 117611
Depends on: 118933
Target Milestone: mozilla0.9.8 → mozilla0.9.9
No longer depends on: 40988
Depends on: 81567
Keywords: nsbeta1
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..
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. ***
Depends on: 124178
Depends on: 124683
Depends on: 124685
Depends on: 124686
Pushing to mozilla1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Depends on: 125205
*** 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.
http://groups.google.com/groups?hl=en&group=netscape.public.mozilla.dom&selm=3C6A9F3F.3050508%40softhome.net
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 ;-)
Depends on: 129115
Depends on: 129496
Depends on: 129953
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.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.0.1
Um, that was a comment from me, not from Nisheeth.
Depends on: 131400
*** 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 
address: ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-04-17-03-WIN_GMAKE/

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
http://www.dynamic-core.net/scripts/code/vectorsine-400-400-js.htm
http://www.dynamic-core.net/scripts/code/blobs-800-400-js.htm

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 ;)
Blocks: advocacybugs
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.

Overflow
The browser's inability to handle the overflow property
Depends on: 117601
Depends on: 128901
Depends on: 136688
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).
Depends on: 139445
Ok. Next tests.
http://alladyn.art.pl/gandalf/MozillaTests

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

Didn't checked on Linux/Mac.
Zbigniew,

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
   Thorsten
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...
Depends on: 139986
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


http://www.24fun.com/downloadcenter/benchjs/benchjs.html


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; 
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
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?
Yup.
Windows only. But not only DX8.0 - 8.1 too

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

greets
Try the experimental builds of bug #129115
(http://ftp.mozilla.org/pub/mozilla/nightly/experimental/bug-129115)

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

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.
Depends on: 102321
Ronald. Hope it fix Windows problem too?
Your results are quite good. Not as good as IE6, but much better than todays 
Mozilla's.
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.

Windows:
				        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+)
Gecko/20020428
** These numbers may not be of much use in a comparison as IE/Mac doesn't
support opacities
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 
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.

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 
http://ftp.mozilla.org/pub/mozilla/nightly/experimental/bug-129115/) 

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 
important change!!!
Depends on: 140167
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
seconds
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 :)
Blocks: 142969
Blocks: 113492
Depends on: 115247
Depends on: 149216
Keywords: nsbeta1- → mozilla1.1
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)
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.

Jake
removing defunct URL from URL field.

Jake
URL: sample 13, http://206.9.170.23/w3CDom... → sample 13
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:
http://alladyn.art.pl/gandalf/MozillaTests/ )
2) At all big problems with moving/cliping and working with big GIF/JPG in Layer
(only on Windows). (link: http://195.205.142.60/gandalf/bolcz/ ;
http://195.205.142.60/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.  

http://333creativecentral.com/faders/fade.htm

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.
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 
relating bug(s).

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.
Blocks: 154568
No longer blocks: 154568
Depends on: 154568
Depends on: x-files
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.


P.S:
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
Depends on: 155160
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.
Depends on: 157401
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.

Shelby Moore
CEO 3Dize, Inc. (CoolPage.com)
CEO DownloadFAST.com, Inc.


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

shelby@coolpage.com

* 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
"guarantee".
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).

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 
project.

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 : darkwolf@m6net.fr) too much CC's annoyed (including me), this is not a 
forum. 
----------------

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


Nicolas Combelles - www.udhtml.com
Depends on: 100%CPU-bg
Depends on: 157681
Depends on: 140748
No longer depends on: 140748
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.
http://www.13thparallel.com/?issue=2002.07&title=sigslots

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 
staggered.

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

Anyone see the same thing or is it just me?

:rob


tested on 2002072514, wXP
I don't know if this one is already covered by one the endless bugs...

1) http://cross-browser.com/examples/clip0.html
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:
http://www.dynamic-core.net/greym/archives/00000016.php
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!!!

http://www.cross-browser.com/ss/solar_system.html

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.
Depends on: 123668
Blocks: majorbugs
Blocks: 164421
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 ... 

www.mindonfire.com

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.
Depends on: 164931
Depends on: 137577
Depends on: 69354
Depends on: 77948
Depends on: 169247
Depends on: 159512
Depends on: 169748
Depends on: 170272
Depends on: 46257
There are still regrettably big differences of performance between Mozilla and
Netscape.
Please,look at this DHTML animation on IE6, then on Mozilla:
http://mozilla.tlk.fr/dhtml_blobs.php
The IE6's speed is incredible!
Depends on: 177958
Target Milestone: mozilla1.0.1 → ---
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.
Depends on: 170702
Depends on: 186133
Depends on: 186465
Depends on: 170330
Depends on: 190193
Depends on: 191474
Depends on: 169531
Depends on: 193849
Depends on: 194627
Depends on: 188331
Depends on: 195883
Depends on: 197341
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Depends on: 199630
Depends on: 154926
Depends on: 69803
Keywords: mozilla1.1
Depends on: 201082
Depends on: 195408
No longer depends on: 154926
Depends on: 169559
Depends on: 203698
Depends on: 210525
Depends on: 210602
Depends on: 212264
Depends on: 83536
Depends on: 212831
Depends on: 164084
No longer depends on: 74826, 82924, 107634, 128901, 139445, 157406, 203698
Depends on: 74826, 82924, 107634, 128901, 139445, 157406, 203698
Depends on: 218650
Depends on: 220937
Depends on: 213813
Depends on: 229391
Depends on: 234233
No longer depends on: 169559
Depends on: 137584
Depends on: 243726
Depends on: 243725
Depends on: 267179
just cleaning up bugs that have been resolved in some way, be it
fixed/invalid/WFM or whatever
No longer blocks: advocacybugs
No longer depends on: 129115, 129953, 131400, 139445, 140167, 149216, 154568, 155160, 157401, 157406, 159512, 164931, 169748, 170272, 170702, 177958, 186133, 190193, 191474, 195883, 199630, 203698, 243726, 21879, 38378, 46257, 65509, 69354, 70100, 74826, 75121, 78826, 81567, 82924, 83088, 83536, 84891, 87808, 93766, 95007, 97287, 97938, 98066, 98627, 98828, 102321, 104593, 107634, 110029, 110246, 117061, 123668, 124178, 124683, 124685, 124686, 128901
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.
Blocks: advocacybugs
Depends on: 129115, 129953, 131400, 139445, 140167, 149216, 154568, 155160, 157401, 157406, 159512, 164931, 169748, 170272, 170702, 177958, 186133, 190193, 191474, 195883, 199630, 203698, 243726, 21879, 38378, 46257, 65509, 69354, 70100, 74826, 75121, 78826, 81567, 82924, 83088, 83536, 84891, 87808, 93766, 95007, 97287, 97938, 98066, 98627, 98828, 102321, 104593, 107634, 110029, 110246, 117061, 123668, 124178, 124683, 124685, 124686, 128901
No longer blocks: majorbugs
Depends on: 297294
Depends on: 291386
Depends on: 142994
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
and
Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

p.s: specs of my box: athlon64 3200, 1024MB DDR533, radeon 8500.
Blocks: 396574
No longer blocks: 113492
Assignee: general → nobody
QA Contact: desale → general
Attached file 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?
A
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.
Flags: needinfo?(zoozapper)
(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.
Priority: P2 → P3
Summary: tracking: poor performance using DHTML → [meta] tracking: poor performance using DHTML

No activity for years, closing.

Status: NEW → RESOLVED
Closed: 25 years ago → 3 years ago
Flags: needinfo?(zoozapper)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: