151344 - Poor JavaScript and rollover performance

Status: RESOLVED FIXED

(Camino Graveyard :: Page Layout, defect)

Description

[Paul Merrison]

The menus on the left hand side of the screen track much more slowly than in
Mozilla 1.0.  The menus are still usable although it is much more difficult than
in Moz 1.0 because it takes time to see which meny item your mouse is hovering
over.  This bug was found using Mac OS X 10.1.5 using a 11/06/2002 nightly build.

Comment 1

[saari (gone)]

Interesting, I wonder if this is another event starvation/processing symptom?

Comment 2

[Mike Pinkerton (not reading bugmail)]

i wouldn't say "much more slowly". i can barely notice the difference on my 800,
though perhaps that's not the best machine to test on.

Comment 3

[Winnie Lam]

I can hardly notice any difference too.  I'm using an internet connection over a
LAN, 256 MB memory, PowerPC G4 450 Mhz.  06-13 0.3.0 build on OS 10.1.5.

Comment 4

[Paul Merrison]

I've checked again on my 500Mhz iBook, and when Chimera is the only app running the 
delay is present but perhaps not as severe as I made it seem above.  When I use 
Chimera with a couple of apps in the background (for example Mozilla 1.0  and MS 
Word, Mail) the menu performance is worse in Chimera than in Mozilla, although still 
usable.

Comment 5

[Mike Pinkerton (not reading bugmail)]

richard writes...

"In short, during the same run through the event loop, we call
setNeedsDisplayInRect: on the area of the link, and then we call it again on the
progress text in the lower left.  On the next pass through the event loop, Cocoa
sees that two areas within the same view (probably the NSTabItem) have been
invalidated, unions the rects, and redraws the whole thing.  That means to
rollover a link near the top of a page, it has to redraw the whole damn page."

Are we sure it's cocoa doing it, not our own widget update code?

Comment 6

[Simon Fraser [no longer active]]

Attachment: Simple testcase: single link with :hover style

Comment 7

[Richard Schreyer]

We should be able to solve this by marking one of the views in the hierarchy as
opaque, so the NSTabViewItem ContentView doesn't have to do any redrawing itself
underneath the link.  By marking CHBrowserView as opaque, rollover performance
significantly increased (and QuartzDebug showed it was only drawing in the right
places).

Unfortunatly, it also caused a bunch of other redraw problems (such as newly
exposed areas of the view not updating when scrolling, etc), and I don't know why.

Comment 8

[Mike Pinkerton (not reading bugmail)]

*** Bug 154947 has been marked as a duplicate of this bug. ***

Comment 9

[Prachi Gauriar]

For a better testcase to see how rollover performance really dies (particularly
with CSS), check out http://comp.uark.edu/~pgauria/

Try any of the links, or links in the sidebar. I can literally sit there and
wait a second for the rollovers to occur.

Comment 10

[Greg K.]

*** Bug 164561 has been marked as a duplicate of this bug. ***

Comment 11

[Mike Pinkerton (not reading bugmail)]

i just made a simple test app with a custom view that toggles its fill color
when clicked and a text area at the bottom of the window that changes text when
the mouse is down/up in the custom view.

with quartzdebug on you can see the bounding rect of the textfield and the
custom view is repainted.

this is a bug in cocoa and should be apple's responsiblity. i'll work on
escalating through ADC.

Comment 12

[David Haas (gone, not reading mail)]

Attachment: 95% fix

heck, I don't want to wait for 10.3 for this to get fixed ;)

by forcing an immediate redraw of the status text field when it gets updated,
we can almost always avoid unioning with whatever's in the browser content view
& a redraw of most of the screen.

You can see how this work (and where it doesn't) pretty well at 

http://developer.apple.com/techpubs/macosx/Cocoa/CocoaTopics.html

scroll over the bunches of hyperlinks to documentation, and watch the fast
updating.  Actually, it's fast enough so that the switch from "link location"
-> "Document:Done" -> "new link location" is a little disconcerting.  

the problem this won't fix seems to be related to image bars with updatable
text type things.  For example, scroll over the  "membership / technical /
business / etc" imagebar at the top of the apple dev screen, and notice how
quartz is unioning with the status bar & redrawing the whole screen again.

Comment 13

[David Haas (gone, not reading mail)]

Attachment: fixed nib

I made the status string draw a background (which happens to be window
background colored), which makes it opaque, which (as mentioned in comment 7)
fixes the problem.  And it's all done in the nib.

It looks to me like there might be a little color offset based on the
positioning of the text field noticable right where it overlaps the progress
bar.  but maybe i'm nuts.

Comment 14

[Mike Pinkerton (not reading bugmail)]

so i tried making this change in the jaguar devtools and the "draws background"
checkbox won't stay checked for the NSTextField that's the status bar.

bug? or am i doing something wrong?

Comment 15

[David Haas (gone, not reading mail)]

It's finiky.  I had to click on the background color picker first, then click on
the draws background square.

Comment 16

[Mike Pinkerton (not reading bugmail)]

that still didn't work for me. :( catch me on irc if you can.

Comment 17

[Mike Pinkerton (not reading bugmail)]

fixed. we went with setting the attributes in the BWC so we could comment them
and make sure they don't get accidently unset.

thanks for the help everyone!!!

Comment 18

[RalphNumbers]

This was broken again in the 2002090305 and 2002090405 builds.  Rollover drawing
returned to it's old slow behavior of redrawing most of the page for every
mouseover.

This seems to be a regression.

I recomend this bug be reopened.

Comment 19

[Mazie Lobo]

Confirming Ralph Numbers, and reopening bug.  These are the results I get when
testing the rollovers on Chimera. 

Build id                     Results
---------------------------------------------
2002082805                   Slow rollovers
2002082905                   Slow rollovers 
2002083005                   Fast rollovers
2002090305                   Fast rollovers
2002090405                   Slow rollovers

Comment 20

[Simon Fraser [no longer active]]

Rollover on the simple testcase attachment is still OK in recent builds, but the
URL test case does show the problem. We need to find a prettier solution that
making the status bar opaque, or perhaps do away with the tab widget shadow
altogether.

Comment 21

[Simon Fraser [no longer active]]

Attachment: Screenshot of clobbered tab widget shadow on 10.1.5

Comment 22

[Mike Pinkerton (not reading bugmail)]

how odd. it looks perfect on 10.2.

Comment 23

[David Haas (gone, not reading mail)]

If somebody's feeling ambitious, they can switch the text field from small
system text font to label text font & tap it down a couple of pixels to move it
out from over the tab widget shadow.

Comment 24

[Simon Fraser [no longer active]]

Or we could lose the tab widget shadow by putting it inside another view. But
that might make things look a bit 'flat'. I don't think we want to increase the
height of the status bar, even by a few pixels.

Comment 25

[David Haas (gone, not reading mail)]

You don't need to increase the height of the status text bar, or make the (for
want of a better term) "status bar area" bigger.

Switching the status text field to label font from small system font makes the
text a little smaller.  Then you can slide the text field down a couple of
pixels, and will still fit inside the superview in the exact same space at the
bottom of the screen but won't be covering up the drop shadow anymore.

Comment 26

[Simon Fraser [no longer active]]

I put the opaque status bar fix back in.