User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 The DHTML performance of DHTML in 1.5 is slower than the previous releases since version 1.1 (I think that was the one that had the DHTML specific enhancements). The problem first appeared in 1.5a (the build that is put on the homepage of mozilla.org). Reproducible: Always Steps to Reproduce: 1. Go to www.terminaldesign.com and mouse over the "Retail Fonts", "Custom Fonts", and "Lettering" navigation buttons. Actual Results: The performance is noticably "laggy" in 1.0 and 1.5. Expected Results: It should have been fast like it is in 1.1 through 1.4. It would be great if this could be fixed before the final release of Mozilla 1.5, as it does not appear to be exclusive to www.terminaldesign.com.

It's not a crasher, so it's not likely to be fixed for 1.5 now, since we're in release candidates. I also can't tell any serious slowness on the menus; or rather, I see the same performance on builds going back to last February as I see now.

On both My machine at work (AMD Athlon XP 1700+, 512 MB ram, GeForce 2 MX 64MB) and my machine at home (AMD Athlon XP 2500+, 1 GB ram, nForce2 (GeForce 4 MX) 128MB ram allocated), the speed drop is extremely noticable. On terminaldesign the menus seems to stall out for a full two seconds before they are eventually drawn to the screen. And if I move over one to the next, it waits the first two seconds, until the menu is drawn, then turns it off, then another two seconds for the next menu. The 3d demo (found in this bug - http://bugzilla.mozilla.org/show_bug.cgi?id=195408) is less than half as fast as it was in previous versions of Mozilla (http://www.world-direct.com/mozilla/dhtml/funo/3dcube/index.htm). Also, this 3d demo, seems to stall every second and a half or so, for just an instant, in Mozilla 1.5. It does not stall in Netscape 7.1 (which as far as I know, is based on 1.4). There is no momentary pause in Netscape 7.0 (based on Mozilla 1.0?). After looking closer at terminaldeisng.com in Netscape 7.0, I noticed that while it is slower than 1.4 and Netscape 7.1 are, it is nowhere near as slow as 1.5 is. 1.5 is actually quite a bit slower (with the menus on www.terminaldesign.com) than 1.0 was. It is odd, that some scripts haven't recieved this same kind of performance loss, like the menu scripts located here - http://www.opencube.com/prod_quickmenupro.html

I assume that you are testing this with the same profile in Mozilla and NS7? I'm only looking at the menu script the bug originally covers; the other URLs should get separate bugs (if they do not have them already). This _could_ also be a platform-specific issue, possibly... (if so, it's a matter of paint events not being processed, I guess).

The bug is that general DHTML performance has dropped, no? These are not the only examples of the slower DHTML performance that I've noticed (they are just the most obvious ones / ones I remembered).

There is no such thing as "general DHTML performance". There are various types of manipulation of the DOM and style data, some of which may have gotten slower while others got faster. There are also issues with event processing that may make perceived "DHTML performance" be either slower or faster. So the guideline, as always with bug reports is "one bug per url" unless you are 100% sure that the underlying code issue is the same on all the URLs involved.

I get your point with the "one bug per url" :-) I still get this problem with two different systems. My work computer, an AMD Athlon 1700+ - GeForce 2 MX 64MB - 512MB system RAM, and my home computer, an AMD Athlon 2500+ - nForce 2 (GeForce 4 MX) 128MB allocated, 1 GB system RAM. My work computer has Mozilla 1.5rc2 installed atm, and has been upgraded through many of the recent releases. It also has both Netscape 7.0 and Netscape 7.1 (and Netscape 4.7x - which doesn't work anymore anyway). They do share the profiles. My home computer is a relatively fresh install of Windows XP and had a fresh install of Mozilla 1.4, which I recently upgraded to Mozilla 1.5rc2. It also has Firebird and Thunderbird installed. Mozilla doesn't even ask me about profiles. Both of those machines have this same delayed menu problem on Terminaldesign.com. I also tested Mozilla 1.5 and Mozilla 1.4 in VMWare running Windows 98 SE. In Windows 98 there is no noticable difference between the two versions (I had 1.4 installed, then upgraded to 1.5). The delay is very noticable on my Windows XP machines. In fact, 1.5 running in VMWare on my work computer (the slower one) displays the menus faster than my home computer! It's very strange, and you are probably right that it is platform specific problem. Also, could the fact that I installed 1.5 over my older 1.4 Mozilla install have something to do with it (even though it worked fine that way in Windows 98)?

Yeah, could be a problem with dispatching paint events on win2k...

Turning on paint flashing, you can see we're repainting the whole content area as you mouse between the menus. Doron said the menus were absolute DIVs, so it seems odd we're doing this much painting.

The site uses visibility, not display, to hide the menus. There is a good chance that this regression dates back to when roc fixed visibility to work correctly (in that kids of a visibility:hidden element can be visible). Still, when visibility changes we should really only invalidate the frame who's visibility changed...

Let me put this on my radar.

This appears to be resolved or I just can't duplicate the problem. Basic Data Windows XP SP1 navigator.appName Netscape navigator.userAgent Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+ navigator.appVersion 5.0 (Windows; en-US) and Basic Data SUSE 8.2 navigator.appName Netscape navigator.userAgent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+ navigator.appVersion 5.0 (X11; en-US)

I still get the slow down on the following Mozillas: Mozilla 1.6b (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208) The latest nightly build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031216) Firebird 0.7 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7). In order to really see the bug, you have to compare the speed of those menus on 1.5 or 1.6 to the speed in 1.1 through 1.4 (or Netscape 7.1). There should be no delay when you mouse over them. It should be instantaneous. This bug also only seems to accur on Windows XP (I haven't checked Windows 2000 or NT) and not Windows 98 (didn't check Linux either). Comment #7 suggests turning on paint flashing. I don't know how to do that, but I bet it's a good idea ;-)

>> Comment #7 suggests turning on paint flashing. I don't know how to do that, but I bet it's a good idea ;-) Should've been comment #8

Paint flashing requires a debug build...

I just found a way to make this problem even more noticable (though it may be a seporate bug). 1. Resized the window to make sure there is a vertical scroll bar (on the right side of the screen). 2. Select from somewhere in the middle of the screen to the bottom, making sure to continue holding the mouse past the edge of the window (or content area). 3. then click somewhere to deselect what has just been selected. When you mouse over the menus they will be even slower than they where before. I have upgraded both my home system and my work system since I filed this bug. While the slow menu performance (before the above mentioned trick) is still noticable, it is much less noticable. So I would say that a slower computer running windows XP is probably needed to see this problem. My older specs where an AMD Athlon XP 1400+ and an Athlon 1Ghz. BTW, did anyone look into the paint flashing thing?

This still worksforme on Linux, even with the steps in comment 15 (p3-733 here). Sounds like a Windows-only problem to me....

(In reply to comment #8) > Turning on paint flashing, you can see we're repainting the whole content area > as you mouse between the menus. Doron said the menus were absolute DIVs, so > it seems odd we're doing this much painting. On the url testcase they've used a transparent gif image (http://www.terminaldesign.com/graphics/dot_clr.gif) that covers almost the entire viewport when you hover over the menu. See this: http://martijn.heelveel.info/test/mozilla/terminaldesign/Terminal%20Design,%20Inc.,%20Digital%20Type%20and%20Lettering%20Design.html I've changed the transparent 1px*1px gif image, by a black 1px*1px image. Almost the whole viewport gets black when hovering over the menu. But this seems much faster than when the transparent gif is used.

My url in comment 17 has changed to: http://wargers.org/test/mozilla/terminaldesign/Terminal%20Design,%20Inc.,%20Digital%20Type%20and%20Lettering%20Design.html

Martijn, URL seems not available. Is this still a problem?

Yeah, my provider accidently wiped out my website. Off course, I had no back-up :( The purpose of my url was to show that this is more like a stupid website thing. Here you can see the url again: http://wargers.org/test/mozilla/terminaldesign/Terminal%20Design,%20Inc.,%20Digital%20Type%20and%20Lettering%20Design.htm

Ok, then WFM.

This is a stupid website thing, and is only noticeable on older hardware, and will be going away on this particular page with a coming redesign - however, it was mentioned that some patch made switching the visibility style between "hidden" and "visible" could be causing superfluous window painting. If that excessive repaint thing is an issue (Comment #8), should it at least be noted in another bug somewhere (perhaps a new one)? I'm not sure how to turn on paint flashing, or I'd make a test page.. The original website still demonstrates the problem (especially if you use ctrl+a to highlight the whole page - that makes it more noticable on newer hardware) though it has gotten a lot better. Even if you highlight the whole page here: http://www.milonic.com/ you don't get the slow down.) Using the clear gif is an old, and silly hack, so if you want to ignore this, I'd have no problem with it (unless it really does demonstrate some other possible performance weekness, that could be fixed).

Please open a new bug for existing problems / slowness.