47210 - Background of client area takes too long for initial paint update during Win32 resize event

Status: RESOLVED DUPLICATE of bug 4545

(Core :: Layout, defect, P3)

Description

[Matthew Mastracci]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20000801
BuildID:    2000080108

The client area of the browser (ie: where the webpage shows) seems to paint last
in a resize event.  On Win32, this should be changed so that the first thing it
does is paint the default webpage background to the new empty area.  As well,
the new scrollbar should be the last thing to be painted on after a resize event.

Reproducible: Always
Steps to Reproduce:
1.  Open up the browser to any page (mozilla.org is fine)
2.  Resize the browser window (use the corner resize)
3.  Watch how the window frame paints long before everything else, giving an
"empty" look to the area.

Actual Results:  see above

Expected Results:  Instead, the "empty" area you can see the windows behind in
should be filled nearly instantly with the default webpage background color.

I don't know exactly which component this should go under...

Comment 1

[Asa Dotzler [:asa]]

I don't see this on my two windows machines. 080108 mozilla M18 build on a PIII
550 (NT4) with 128 MB RAM and a PIII 650 (win98) with 128 MB RAM.  am I too fast
to see this? Others see this so over to layout for a look.

Comment 2

[Asa Dotzler [:asa]]

adding danm to CC:

Comment 3

[Gregory McLean]

With build 2000080113 on Linux (RH 6.2) PII 350 128 Meg. I see simliar behavior,
The window frame appears and a noticeable delay later the window gets filled in.
Could be just the startup time causing this.

Comment 4

[Matthew Mastracci]

My Win32 machine is running Win2k with a dual 550 and 256MB of RAM.  The one
other factor I can see is that it has an ATI card with older drivers.  I haven't
really seen many artifacts in any other Win32 apps during resizing.

I've found the resizing effects to be especially noticable on the preferences
dialog.

Comment 5

[Nisheeth Ranjan]

Re-assigning bugs on Clayton's list opened between 7/29 and 8/4 to Kevin for
further triage.

Comment 6

[Kevin McCluskey (gone)]

This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.

Comment 7

[Kevin McCluskey (gone)]

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