slow performance on menus/filedialogs/other UI components




18 years ago
10 years ago


(Reporter: aheitner, Assigned: hangas)




Firefox Tracking Flags

(Not tracked)




18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.0.36 i586; en-US; m17) Gecko/20000807
BuildID:    2000080712

Not sure if this is really a UI-design issue or a more fundamental XUL issue (i
suspect the latter; i have yet to see XUL perform well).

The machine is a p133; debian slink; 64 megs ram (not hitting swap at all, only
using about 2/3 of ram); mozilla-m17 (the release i686 build).

The UI just performs abysmally. If you click on a menu, then move your mouse
over a bit (to the next menu) it takes about a half-second for the new menus to
draw. If you flip to another virtual screen then flip back, it takes a
rediculously long time to paint. If you click on file->open, it takes a good
half-second after the dialog frame appears for the widgets to actually paint. If
you click on a dropdown list it takes about a second for the values to fill in.

things felt reasonably good with m17 linux on my work machine (GHz pIII). win32
m17 wasn't bad on my pIII-500 laptop, but in chatzilla scrolling the nicklist
was painfull (it scrolled fine but took a good while to fill in).

no reason things should be this slow; Glade stuff (XML-specified GTK UI's) and
PyGtk (scripted GTK UI's) work fine and are perfectly responsive ...

I note that rendering the page itself and scrolling are both fine.

Reproducible: Always
Steps to Reproduce:
1.Uhh, just use the darn thing on a pentium-classic class machine. it's unpleasant.
Please try a nightly build and return here to comment on this, and try to be
more specific, please. This is also a result of XP menu performance, which seems
to have sped up quite nicely lately.
Component: User Interface: Design Feedback → XP Toolkit/Widgets: Menus

Comment 2

18 years ago
Reassigning from bdonohoe to hangas
Assignee: bdonohoe → hangas
Component: XP Toolkit/Widgets: Menus → User Interface: Design Feedback

Comment 3

18 years ago
... And back to XPToolkit/Widgets. John, I'm not sure how useful this bug is, but 
have it anyway. :-)
Component: User Interface: Design Feedback → XP Toolkit/Widgets: Menus
Keywords: perf
QA Contact: mpt → jrgm

Comment 4

18 years ago
Little can be done with this bug report because it mentions far too many issues 
(I counted 4), and instead of detailing each one in-depth, it just glosses over 
them with a sentence or two.  Of the 4 issues identified, I recognized 2 as dups 
(the menu and the dropdown problems), one as being far too general to be helpful 
(widgets take a long time to paint), and one that I didn't even quite understand 
(what's a virtual screen?) but which was also too general.  Please file separate 
bugs for the issues that are still around in a new nightly, and explain each in 
as much detail as possible.  Thanks.
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 5

18 years ago
verified invalid, but point taken -- we are looking at optimization, although
133MHz is at the low end of target devices 


10 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.