48961 - slow performance on menus/filedialogs/other UI components

Status: VERIFIED INVALID

(Core :: XUL, defect, P3)

Description

[Ari Heitner]

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.

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

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.

Comment 2

[leger]

Reassigning from bdonohoe to hangas

Comment 3

[Matthew T (active 1999-2002)]

... And back to XPToolkit/Widgets. John, I'm not sure how useful this bug is, but 
have it anyway. :-)

Comment 4

[Blake Ross]

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.

Comment 5

[John Morrison]

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