199267 - slowdown of preferences window

Status: RESOLVED WORKSFORME

(SeaMonkey :: Preferences, defect)

Description

[haferfrost]

User-Agent:       Mozilla/5.0 (Slozilla - the slowest browser on earth)
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4a) Gecko/20030325

I've noticed a severe slowdown regarding the Preferences Window recently.
Everything is still snappy in 20021202 but now switching panels takes at least
twice the time. The slowdown goes at least back to the official 1.3 release but
probably even further. It looks like Mozilla starts drawing too soon and has to
re-layout stuff several times. When switching to the Navigator panel I saw the
"Choose File" button at the left edge of the Home Page subpanel and it jumped to
the right as the Location text field was inserted. In other panels I see the
radio buttons being drawn and it takes half a second till the black dot appears
in the currently active one. This is a bad and very visible regression for
people who don't have 2GHz Athlons, yet.

Note: This is NOT a duplicate of bug 151637. That bug deals with a much older
version of Mozilla and should have been closed a while ago. This is a new
regression that occured after 2002-12-02.

Reproducible: Always

Steps to Reproduce:
1. Get a "slow" computer such as a K6/2-500
2. Edit/Preferences
3. Switch Panels

Actual Results:  
I see menus slowly manifest themselves, sometimes being rearranged right before
my eyes.


Expected Results:  
Panels should just pop up without me seeing the actual layout process take place.

Comment 1

[haferfrost]

Setting user_pref("nglayout.initialpaint.delay",  1000); or higher makes the
jumping button problem disappear so this regression seems to be caused at least
partially by the new paint timeout (see bug 180241) default value.

Comment 2

[haferfrost]

I've compared 20021202 and 20030325 both with
user_pref("nglayout.initialpaint.delay", 5000) and while this does help 20030325
greatly (you don't see reflows anymore), 20021202 is still much faster when
switching panels.

Comment 3

[haferfrost]

Interestingly, even setting nglayout.initialpaint.delay as low as 10 doesn't
cause 20021202 to show the annoying reflow effects, so the root of the
regression seems to lie elsewhere. Could it be that nglayout.initialpaint.delay
did not have an effect of Preferences until recently? Or maybe something else
has slowed down Preferences so much that reflow is now necessary whereas it
wasn't earlier. In that case my comment 1 would not be accurate. Rather than low
initialpaint.delay values showing the regression, high values would mask it.

Comment 4

[Frank Wein [:mcsmurf]]

Reporter: Do you still see this with a current Mozilla build?

Comment 5

[haferfrost]

I don't have 20021202 anymore for comparison, so I can't comment on the overall
speed of current Mozilla vs the older version. I don't see any reflows, though
in a current build. I won't mind if this bug is closed.

Comment 6

[Frank Wein [:mcsmurf]]

resolving then