36029 - XP Menus Used in Widgets Are Very Slow on Mac OS

Status: RESOLVED WONTFIX

(Core Graveyard :: Widget: Mac, defect, P3)

Description

[Gordon Henriksen]

From Bugzilla Helper:
BuildID:    2000041508

Macintosh users are used to very responsive menus. Mozilla's cross-platform menus (on 
the Macintosh, used only for menus attached to XP widgets) are very unresponsive 
when appearing, tracking mouse movements, and disappearing. They could be sped up 
on the Macintosh by emulating the techniques Apple uses to acheive responiveness 
with Toolbox menus.

The largest latency is caused by the Macintosh's deficient multitasking. Using an 
"uncooperative" event loop while tracking XP menus will avoid the latencies of 
cooperative multitasking. Conveniently, this also prevents another application coming 
to the foreground during menu tracking. (It is arguably undesireable in that it blocks 
other processing, but users are very well-acclimated to that side-effect.) Such 
behavior could be grafted onto a unified event loop by conditionalizing the 
*-NextEvent call: Invoke GetNextEvent if any menus are visible, WaitNextEvent 
otherwise.

A GetNextEvent event loop will require a backing store, as well. If it does not have 
one, it will leave huge unrefreshed blotches on the windows of background 
applications until all menus are dismissed. This bug would merely be an annoyance, 
however, until a backing store is implemented. Use of a backing store is in and of 
itself important for high-performance submenus (and menu bars). With a backing 
store, time-consumg update events directed at windows revealed by disappearing 
submenus need not be involved.

Reproducible: Always
Steps to Reproduce: Use the bookmarks command menu in the personal toolbar, or 
any other menu attached to an XP widget.

Comment 1

[Adam]

Hear! Hear!
Performance issue - adding perf keyword.

Comment 2

[sairuh (rarely reading bugmail)]

sounds like a dup of bug 28106...

*** This bug has been marked as a duplicate of 28106 ***

Comment 3

[Mike Pinkerton (not reading bugmail)]

i concur this is not a dupe, per se. cc'ing other mac weenies.

Comment 4

[Mike Pinkerton (not reading bugmail)]

accepting, but pushing way out.

Comment 5

[Matthew T (active 1999-2002)]

See also bug 34572.

Comment 6

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 7

[sairuh (rarely reading bugmail)]

*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.

Comment 8

[Kathleen :Brade]

This bug seems similar (but not the same) as bug #49129 (which is specific to
bookmarks and other menus built on the fly?).

Clint McIntosh comments on this issue on 11/15/2000 at
http://www.macintouch.com/netscape6.html:

Netscape 6 is VERY slow on my 250MHz 604e CPU w/1MB L2 cache, 130MB RAM. Clicks
on the menubar take almost a full second to register. Clicks within the browser
window take even longer.

Comment 9

[Marcia Knous [:marcia]]

nominating for dogfood (from sdagley's list of bugs that are good candidates for 
our next release) 

Comment 10

[Shoshannah Forbes]

Not sure if this belongs here, or in a new bug:
on OS X, all the menus of Mozilla (file edit view etc) are very much slower then
in other apps.
I am on G3, OS 10.1 with 256 MN ram, and the diffrence between mozilla and other
os x apps is very noticible.

Comment 11

[Mark Mentovai]

They're not slow on OS X (or at least not on any recent version of OS X).  The suggestions in comment 0 are not meaningfully applicable on OS X, especially after the event loop changes, said changes having taken six years to materialize.  34572 is still valid as an RFE.