User-Agent: Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100705 Minefield/4.0b2pre Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100705 Minefield/4.0b2pre Currently, the window is drawn first. While the window is being drawn, the browser chrome (i.e. toolbars)are white until they are drawn. This makes startup seem really slower than it actually is. Reproducible: Always Expected Results: They should be drawn at the same time.

Aero Glass enabled?

(In reply to comment #1) > Aero Glass enabled? Yes but that's irrelevant. Even with aero basic, window/chrome are drawn at different times.

http://planet.firefox.com/ux/ Read "Window Drawing" under "General Observations". Ctrl+F

Isn't this a dup of https://bugzilla.mozilla.org/show_bug.cgi?id=574638

(In reply to comment #4) > Isn't this a dup of https://bugzilla.mozilla.org/show_bug.cgi?id=574638 No. Bug 574638 only occurs because of some drawing issue. Even if it didn't occur, it'd still get drawn after the window. This bug deals with loading them at the same time.

I think the real bug here is that content does not paint as quickly as os generated window chrome. Although now that we are moving toward painting the chrome ourselves, the whole window will likely seem to load slower. We'll no doubt be visiting these issues over the next few months.

Is there any reason we should be showing the window at all until we are ready to paint the chrome (e.g. initial onload of the chrome doc is complete, and initial reflow is complete)?

Only if we need that to do sizing correctly....

On Windows at least we can create the window and just avoid showing it, that should still allow all the sizing to be correct.

We currently set the margins on the window via script in BrowserStartup. Is there any chance we might be reflowing/repainting twice? http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#4730

You could check. Set a breakpoint in reflow and one in whatever place you think we should only reflow once by and see how many times we reflow?

(In reply to comment #11) > You could check. Set a breakpoint in reflow and one in whatever place you > think we should only reflow once by and see how many times we reflow? Hmm, doesn't appear to be the problem. We set the margins before the window is visible. Next the window is display w/no content yet, then we paint, set the glass margins, and the base level ui fills in. Let me post a couple screen shots.

So prior to the display of the top window in this series, we call SetNonClientMargins twice, once from browser.js and once from xul window via persisted attributes, then the window displays (top frame). Next we get our first full paint/glass update/content shown (middle frame), then a few paints later we get child widget updates w/proper background (bottom frame). The first frame here is where the white flash comes from.

If we delayed calling show until the second frame, and fixed the background color, we'd be in pretty good shape.

Aero basic follows the same steps, but the result is slightly different. Looks like the sub widgets for tabs aren't being shown early enough.

Tabs are losing widgets soon anyway, so maybe that's not a big deal.

We might be showing the initial frame sooner now that we've removed the top level child widget. Rather than hide it longer though I'd rather get painting happening sooner!

So what delays painting? One good think to look into may be what the callstack to PresShell::UnsuppressAndInvalidate for the root presshell looks like.

(In reply to comment #18) > So what delays painting? One good think to look into may be what the callstack > to PresShell::UnsuppressAndInvalidate for the root presshell looks like. Really not sure yet, will try to trace out from the initial show event in widget to see.

For some reason, the initial draw seemed to last a little bit longer when I launched Firefox from the profile manager (as opposed to launching directly without displaying the profile manager first). I have no idea why though, and it could have just been a warm start versus cold start. Either way the video shows Firefox being launched from the profile manager, in case that is for some reason relevant.

This might be completely unrelated, but what happens if you make nsWindow::Update() a no-op?

(In reply to comment #23) > This might be completely unrelated, but what happens if you make > nsWindow::Update() a no-op? Doesn't appear to be called during startup.

OK. Then I'd check what happens to the first paint event. Do we answer it by painting white the first time? Or is it only sent after the window has already been shown?

(In reply to comment #25) > OK. Then I'd check what happens to the first paint event. Do we answer it by > painting white the first time? Or is it only sent after the window has already > been shown? Looking at that now. The delay on the first paint event is too long. PresShell's UnsuppressAndInvalidate is called early on, so the doc is loaded and I presume, ready for painting. Then we call Show() on the widget, which displays the window with a busted frame, then a short while later, the first paint comes in and the chrome shows up. I'd like to find a way to force that first paint sooner.

(Removing relnote, this isn't relnote-worthy IMO)

(In reply to comment #26) > (In reply to comment #25) > > OK. Then I'd check what happens to the first paint event. Do we answer it by > > painting white the first time? Or is it only sent after the window has already > > been shown? > > Looking at that now. The delay on the first paint event is too long. > PresShell's UnsuppressAndInvalidate is called early on, so the doc is loaded > and I presume, ready for painting. Then we call Show() on the widget, which > displays the window with a busted frame, then a short while later, the first > paint comes in and the chrome shows up. I'd like to find a way to force that > first paint sooner. FWIW, forcing an early paint wasn't possible. The only chance was during the initial show, but painting is suppressed at that point by the view manager. We might be able to move the non-client set to a later point though, so that windows draws the native frame until we are ready to paint the new titlebar.

Why was this moved to Firefox/Theme?

Why is painting suppressed during the initial show? Do we need to move the initial show to an event? I really think we should show the window and immediately UpdateWindow to paint it.

What does the call stack of the paint event you forced during the initial show look like? On Mac we paint during the initial show and painting isn't suppressed. Does that forced paint event send an NS_WILL_PAINT event before the NS_PAINT event?

We're in the middle of a resize reflow w/the view manager doing a batch update. Theme might not be the best place for this, we might be able to delay the show until after the reflow takes place and the batch update is complete.

(In reply to comment #31) > What does the call stack of the paint event you forced during the initial show > look like? On Mac we paint during the initial show and painting isn't > suppressed. I'll post a stack in a sec. > Does that forced paint event send an NS_WILL_PAINT event before the NS_PAINT > event? yes, always. that's part of our normal painting.

(In reply to comment #32) > We're in the middle of a resize reflow w/the view manager doing a batch update. Oh, I see. So before the draw-in-titlebar patch, at this point we were only making a child window visible inside a still-hidden top level window, right? And it didn't actually become visible on the screen until the containing top level window was made visible in nsXULWindow::SetVisibility? > we might be able to delay the show > until after the reflow takes place and the batch update is complete. Would nsXULWindow::SetVisibility be a good place for the show?

If we force a sync paint on Show(), we'll always end up here in view manager: http://mxr.mozilla.org/mozilla-central/source/view/src/nsViewManager.cpp#846 Which results in a black background being painted for the main window, and looks far worse than what we have now.

(In reply to comment #34) > (In reply to comment #32) > > We're in the middle of a resize reflow w/the view manager doing a batch update. > > Oh, I see. So before the draw-in-titlebar patch, at this point we were only > making a child window visible inside a still-hidden top level window, right? > And it didn't actually become visible on the screen until the containing top > level window was made visible in nsXULWindow::SetVisibility? Yes, exactly. > > > we might be able to delay the show > > until after the reflow takes place and the batch update is complete. > > Would nsXULWindow::SetVisibility be a good place for the show? Originally it was shown when the chrome loaded event fired. We landed a patch that suppressed the Show in document viewer, but this had a number of problems and had to be backed out. At some point this needs to be revisited, there's an open bug on it (bug 579421). If you set the paint delay timer way down to zero, we actually get the window to display even sooner, before the chrome loaded event fires.

(In reply to comment #36) > (In reply to comment #34) > > Would nsXULWindow::SetVisibility be a good place for the show? > > Originally it was shown when the chrome loaded event fired. OK. nsXULWindow::OnChromeLoaded() calls nsXULWindow::SetVisibility. > We landed a patch > that suppressed the Show in document viewer, but this had a number of problems > and had to be backed out. At some point this needs to be revisited, there's an > open bug on it (bug 579421). I think revisiting it now should be the way to go. To me it looks like that will, in combination with bug 130078, fix this bug.

Bug 130078's basically getting ready to land so can someone mark this blocking final+?