Closed
Bug 151344
Opened 22 years ago
Closed 22 years ago
Poor JavaScript and rollover performance
Categories
(Camino Graveyard :: Page Layout, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Chimera0.6
People
(Reporter: p.m.merrison, Assigned: mikepinkerton)
References
()
Details
(Keywords: perf)
Attachments
(3 files, 1 obsolete file)
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•22 years ago
|
||
Interesting, I wonder if this is another event starvation/processing symptom?
Assignee: saari → pinkerton
Assignee | ||
Comment 2•22 years ago
|
||
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.
Status: NEW → ASSIGNED
Target Milestone: --- → Chimera0.5
Comment 3•22 years ago
|
||
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.
Reporter | ||
Comment 4•22 years ago
|
||
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.
Assignee | ||
Comment 5•22 years ago
|
||
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?
Updated•22 years ago
|
Summary: Poor JavaScript Performance → Poor JavaScript and rollover performance
Comment 6•22 years ago
|
||
Comment 7•22 years ago
|
||
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.
Assignee | ||
Comment 8•22 years ago
|
||
*** Bug 154947 has been marked as a duplicate of this bug. ***
Comment 9•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Target Milestone: Chimera0.5 → Chimera0.6
Comment 10•22 years ago
|
||
*** Bug 164561 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 11•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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.
Attachment #97088 -
Attachment is obsolete: true
Assignee | ||
Comment 14•22 years ago
|
||
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•22 years ago
|
||
It's finiky. I had to click on the background color picker first, then click on the draws background square.
Assignee | ||
Comment 16•22 years ago
|
||
that still didn't work for me. :( catch me on irc if you can.
Assignee | ||
Comment 17•22 years ago
|
||
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!!!
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 18•22 years ago
|
||
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•22 years ago
|
||
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 20•22 years ago
|
||
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.
Severity: minor → normal
Keywords: perf
Comment 21•22 years ago
|
||
Assignee | ||
Comment 22•22 years ago
|
||
how odd. it looks perfect on 10.2.
Comment 23•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
I put the opaque status bar fix back in.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•