Closed Bug 220937 Opened 21 years ago Closed 19 years ago

The performance of the menus on terminaldesign.com are significantly slower in 1.5 than previous versions of Mozilla

Categories

(Core :: Web Painting, defect, P2)

Product:
Core
Component:
Web Painting
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: CaptainN, Assigned: roc)

References

(
URL
)

Details

(Keywords: perf, qawanted, regression) 

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.
Keywords: qawanted
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.
Assignee: general → roc
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Blocks: 21762
Component: Browser-General → Layout: View Rendering
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.
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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
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.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.