Closed Bug 11355 Opened 25 years ago Closed 23 years ago

very slow in mousing over link

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: karnaze, Assigned: shaver)

References

(
URL
)

Details

(Keywords: perf) 

Mousing over the links "home", "screen saver", etc. is extremely slow and
visually unappealing. One of the problems is that nsTableOuterFrame::Paint is
being called about 8 times just by moving the mouse over a link. Tables are not
being reflowed during mouse over. This was discovered in bug 8950 (see
attachments there if necessary).
Assignee: troy → karnaze
I don't know why this bug is assigned to me. If you look at the source you'll
see that on mouse over and mouse out the script changes the image src URL. That
causes the image frame code to invalidate its bounds and hence there's a
repaint, once on mouse over and once on mouse out.

Because we do painting in three passes (ask Kipp about this), you'll see a bunch
of calls to the outer table (at least six I would expect) because the image
that's changing is inside of the table and painting is a recursive process

I would guess that the table painting code isn't very optimized, or the painting
pipeline in general isn't optimized.

Neither of these issues are me, though.
Assignee: karnaze → rickg
Rick, please don't give this back to me. I put print statements (I couldn't find
my reliable timer) upon entering and leaving nsTableOuterFrame::Paint and got
the impression that it was not too slow, but being called too many times. It
might even have to do with (the style system) looking up visited links.
Assignee: rickg → karnaze
Chris -- not so fast. You own the table code, so the buck stops with you on
making sure it gets fixed. I suggest you get peter and troy (and kipp) on the
phone and work this out.
Assignee: karnaze → peterl
I copied the source of the url locally and put <base href=... in the head and
the performance was acceptable. And the same large number of calls were being
made to nsOuterTableFrame::Paint.

Peter, if this is not related to the style system, could it be Necko related. If
so, please reassign to Gagan.
Assignee: peterl → karnaze
The only result of style system interaction is a single call to AttributeChanged
on the image frame, which in turn does nothing but invalidate the frame (no
network involvement since the images in question are already loaded).

Frankly I don't see any performance problem here, but the only possible culprit
could be paint code.
Status: NEW → ASSIGNED
Target Milestone: M12
Assignee: karnaze → vidur
Status: ASSIGNED → NEW
Target Milestone: M12 → M11
Vidur, I recently tried this page and when mousing over the links (HOME, SCREEN
SAVERS, etc) I get the following error. Nav4.6 doesn't have a problem with the
javascript. Please reassign back to me when this is fixed.

JavaScript error: imgOff is not defined
Preliminary: as with any live website, what was served today is not
necessarily what was served yesterday, so these comments may have little
or nothing to do with what was previously observed.

Communicator 4.7 and Mozilla M11 build 1999101109 both loaded this page
in ~60 seconds the first time, ~40 seconds the second time, on an NT box
with a Pentium 75 and a 28.8 modem. However, after apparently drawing the
entire page and greying out the Stop button, Mozilla seemed to continue
receiving data for at least several minutes, to no effect and for no
apparent reason. The data flow could clearly be seen on an external modem,
much more Rx than Tx, and no, nothing else was running. I wish I could say
for sure what was being received, but it was almost certainly being received
by Mozilla, as the data flow continued for ~10 seconds after clicking on the
Back button, before the previous page began to load.

Trying the mouseover, with Moz M11 no second image was displayed for any
of the navigation buttons, but as the mouse pointer left the region,
a blank white rectangle with the "image loading" icon (not the
"broken image" icon) was momentarily displayed for all of the mouseover
regions.  Nav 4.7 took ~3 times as long to display the second image for the
mouseover regions as for two other comparably complex pages.

Speculation: I can't comment on the quality of the javascript code on this
page, but could the fact that there are TWO distinct
<SCRIPT LANGUAGE = "JavaScript"> elements on the page have anything to
do with this?

Speculation: while it is believable that Mozilla's javascript code still
has some bugs in it, it is also believable that the page's javascript
script has bugs in it also, even if Nav 4.x can display the page as intended.

Regardless, the continued network activity is problematic.
Question: could this have been the cause of the mouseover problem
all along, or could this page triggering be triggering TWO bugs
in Mozilla?
Target Milestone: M11 → M13
Moving to M13.
http://www.dilbert.com/ has a similar problem, but the mouseovers are
intermitantly fast and slow (P3 450). The network problem is still present
though.
Build ID: 1999111520 WinNT 4 SP 6.
Sorry, that should have been the network problem is NOT present.
Is this bug related to bug 7550?
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
Related to 20110, though it seems that in this case we're actually reloading the
images everytime.
Assignee: vidur → shaver
Status: ASSIGNED → NEW
And since I'm in a reassigning mood, I'll pass this one along with bug 20110 to
shaver.
*** Bug 23441 has been marked as a duplicate of this bug. ***
Keywords: perf
Summary: [PERF] very slow in mousing over link → very slow in mousing over link
Status: NEW → ASSIGNED
Target Milestone: M13 → M14
I think 21879 will help us here, and maybe the new timer work.
Looks like this is mine.

This happens because when you move over a link the status text resizes causing a 
reflow. It mistakenly relows the content area and the table as well. Its 
currently fixed in my build. I'll mark it fixed when I get it checked in.

-E
Assignee: shaver → evaughan
Status: ASSIGNED → NEW
Whiteboard: Fixed will checkin soon
Opps I was wrong this is a table thing. The images changes in the table.
Assignee: evaughan → shaver
Whiteboard: Fixed will checkin soon
How come this is still M14? M14 is already out!
Mass moving old milestone bugs to M16
Target Milestone: M14 → M16
Tested with Build # 2000060408 on Win 98 SE
Fixing bug 21879 seems to have fixed this bug. All mouseovers respond correctally.
Works for me.

Can we get some feedback on other platforms, ideally from the reporter?
Status: NEW → ASSIGNED
Tested with Build 2000060815 on Red Hat 6.2
Works in Linux

Testing on an old Pentium 75 box running WinNT, Mozilla 2000-06-13-08-M17
diplayed the mouseovers correctly, about a factor of two slower than NN 4.7.

NN 4.7 displays the rollover images on the screensaver page just fast enough
to not feel any more sluggish than anything else on that machine, while
Mozilla M17 is just slow enough for the sluggishness to be annoying.

Same basic result on a K6-300 machine: although much faster, Mozilla's
rollover display still felt a bit sluggish compared to other mouseover effects
in Mozilla and other apps. No unappealing transient visual effects, though.

Same result for both the original URL and the Dilbert page, although the 
rollovers on the the latter page are much faster in both browsers than those
on the screensavers page.

So it's no longer extreme, but there is still something of a performance 
problem...
M16 has been out for a while now, these bugs target milestones need to be 
updated.
what's going on with this bug, Mr. Shaver?
Depending on whether you see this bug as ``abysmally slow mouseover
performance'' or just ``slower than 4.x mouseover performance'', it might or
might not be closed.

I'm going to go with the former, I think, because it's not clear that 4.x
performance parity is a real goal for right now.

It seems like this might be related to our problems with loading images from the
cache: we're seeing that rollovers are causing things to always be fetched from
the network, bypassing the image, memory and disk caches.

Copying some image experts for guidance (and bug-depends-on settings).

Is this still a problem with the latest nightlies?
Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.
Under a Mandrake 7.2 system (P2 433, 128M ram, voodoo5, latest patches) the Mozilla .8 mouseover behavior is *extremely* slow on a JScript that is otherwise extremely fast on every other browser and platform on earth.  

The source code and example page I used is http://www.simplythebest.net/info/dhtmscript24.html.  I really and truly suspect that this is still a bug in Mozilla's code that has not been fixed in subsequent builds.
Target Milestone: M16 → ---
peterson, can you verify that this is still a problem on Win32?
All testcases listed here seems to work pretty well now.
Bug #20110 seems to be this same, and its fixed lately, suggest
closing this too.

Tested on linux build 2001042021.

Very fast for me, too. Marking worksforme.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.