If you resize an open apprunner window, you can see the desktop wallpaper or other apps running on your machines 'through' the apprunner window for a short while (apprunner will eventually draw its window correctly). This is either a performance issue (I can't see the same behavior in 4.51 - is it because it's faster?) or else it's a bug.

Re-assigned to chofmann@netscape.com. Chris, any idea who should get this one???

jevering, we need some serious profiling and performance work..

Putting on [Perf] radar

Moving all Apprunner bugs past and present to Other component temporarily whilst don and I set correct component. Apprunner component will be deleted/retired shortly.

With the latest builds 1999080408 on all 3 platforms, this seems to have been fixed.

Bulk add of "perf" to new keyword field. This will replace the [PERF] we were using in the Status Summary field.

jev: you still want this bug? looks like a reflow problem that should get assigned to a layout monkey.

leger, can we get some folks to pound on this and see if if the problem still exists in any form, and close if not.

I see this on linux, too if I change this code: http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsWindow.cpp#1593 from: SetBackgroundColor(NS_RGB(192,192,192)); to: gdk_window_set_back_pixmap(mSuperWin->bin_window, NULL, 0); The problem is that the background color on a window isn't set from a document so the operating system never sets a background color when increase the size of the window. I set the background color on windows be default because if you don't then then it does look like crap when you change the size of the window. Looks like windows has the same kind of issue.

ok, now we might getting somewhere.. rods, kmcclusk, danm, and law look like they have poked about in http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/widget/src/windows/nsWindow.cp p can you review blizzard's work and see how it might be applied to win32?

Updating QA contact.

changing qa contact to jrgm@netscape.com on some random bugs

reassigning jevering's old bugs to jar for adoption or to find them a new home

This really seems like a layout problem, where refresh is not being called on some region (if I understand the bug description) for a "long time." Blizzard suggested a call to get the background cleared sooner, which seems like an excellent way to deal with this. In truth, this is IMO No Big Deal either way. It would be nice if we were fast enough to get around to painting the region before the user noticed it... but I've seen this class of "problem" in many shipping apps.

Okay -- enough churn. Kevin: will you please take a look? Thanks.

This bug really happens by design. We do not clear the window when it is resized because we will paint the window after reflowing and processing all paint messages. We could clear the window immediately (presumably to the background color specified for the body), but then we end up doing double paints.

This bug is marked "future" because it is not critical for RTM (Release To Manufacturing). If anyone believes it is critical, please explain why in this bug.

Do we still have this bug? I do not see it on Mtrunk 2000111108 on duron 963.

(most of this is Windows related, I can't test on other platforms) I still see this in Windows 98 on an AMD K6-2 450MHz, using Mozilla build 2000121508. This is apparent on pretty complex pages like voodooextreme.com, while the effect is harder to spot on simpler pages. It seems that IE fills the unpainted space with "application background" color from Windows settings. Resizing pages in IE with background of color other than the "application background" color yields the behavior where as soon as the resized windows is drawn, the "application background" color fills the space as soon as possible (the impression is that Windows paints the resized window along with the filler application background in one pass), then the rendered page takes the occupied space. So, do we want to mimic IE's behavior of immediately clearing the window with the system "application background" color? Kevin pointed out that we end up doing double-paints if we were to paint the background using the background color of the page. However, painting the background using "application background" color does not require accessing the page or knowing *anything* about the page being painted. So, might it be relatively painless to do this "application background" color filling on a platform-specific level (like nsWindow.cpp in widgets/src/windows), so to speak? I think that the performance impact would be small (just painting a single-color box).

*** Bug 63232 has been marked as a duplicate of this bug. ***

*** Bug 48532 has been marked as a duplicate of this bug. ***

*** Bug 47210 has been marked as a duplicate of this bug. ***

FYI, the patch in bug 72230 sets the window background color for empty webshell windows so the OS toolkit will automatically paint the window.

This bug was fixed several months ago by a checkin which sets the background color for the widget when we are in-between page loads.