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 2 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.
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://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: