Last Comment Bug 1336227 - Show a window as soon as possible after start-up, even if it's not showing any UI yet.
: Show a window as soon as possible after start-up, even if it's not showing an...
Status: NEW
:
Product: Core
Classification: Components
Component: Widget: Win32 (show other bugs)
: 50 Branch
: Unspecified Unspecified
-- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jim Mathies [:jimm]
Mentors:
https://phlsa.github.io/photon-perfor...
Depends on:
Blocks: photon
  Show dependency treegraph
 
Reported: 2017-02-02 14:34 PST by Mike Conley (:mconley)
Modified: 2017-02-16 08:37 PST (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Mike Conley (:mconley) 2017-02-02 14:34:27 PST
As part of our efforts to improve perceived performance, one of the things that the UX team has identified coming out of the Photon work is that we want the initial browser window to appear instantaneously.

This is true _even if we haven't figured out how to lay out the UI yet_. The way that Chrome does this is by displaying a blank, undecorated window very soon after process start. Edge shows a splash screen (an idea which we've evaluated and discarded).

By showing a window more quickly, we also (I believe) get the Firefox icon into the taskbar more quickly.

We should be using Edge as our timing benchmark here, since it appears to be fastest. The request from UX is that we beat or at least be at parity with Edge on showing something after startup.

Putting this under Widget: Win32, since I think this is likely going to be platform specific, and if we start anywhere, it's going to be Windows.
Comment 1 User image Mike Conley (:mconley) 2017-02-02 14:39:30 PST
We might want to speak with the Hasal[1] folk to see if their framework could possibly be instrumented to give us real concrete numbers on how Edge performs here, to give us a raw number to beat.

[1]: https://wiki.mozilla.org/Hasal
Comment 2 User image :Harald Kirschner :digitarald 2017-02-02 16:22:13 PST
(In reply to Mike Conley (:mconley) from comment #1)
> We might want to speak with the Hasal[1] folk to see if their framework
> could possibly be instrumented to give us real concrete numbers on how Edge
> performs here, to give us a raw number to beat.

Just recording the effects on a representative machine should be enough to have a side by side comparison. This could even be done on low, mid and high tier laptop.

How well is this instrumented in Telemetry currently? Do we know the breakdown of startup or would it make sense to add better probes (window visible, tabs painted, window interactive)?
Comment 3 User image Mike Conley (:mconley) 2017-02-06 13:03:19 PST
(In reply to :Harald Kirschner :digitarald from comment #2)
> (In reply to Mike Conley (:mconley) from comment #1)
> > We might want to speak with the Hasal[1] folk to see if their framework
> > could possibly be instrumented to give us real concrete numbers on how Edge
> > performs here, to give us a raw number to beat.
> 
> Just recording the effects on a representative machine should be enough to
> have a side by side comparison. This could even be done on low, mid and high
> tier laptop.
> 
> How well is this instrumented in Telemetry currently? Do we know the
> breakdown of startup or would it make sense to add better probes (window
> visible, tabs painted, window interactive)?

It looks like nsIAppStartup's getStartupInfo will return information on a bunch of start-up timeline information - specifically, these: http://searchfox.org/mozilla-central/rev/f5077ad52f8b90183e73038869f6140f0afbf427/toolkit/components/startup/StartupTimeline.h#6-21

This information is submitted to Telemetry under "simple measurements", and should be represented as "number of milliseconds that we hit this point in the timeline in ms".

So the ones we probably care about are createTopLevelWindow and firstPaint.
Comment 4 User image Jim Mathies [:jimm] 2017-02-08 12:22:58 PST
mconley, any sense of priority on this?
Comment 5 User image Mike Conley (:mconley) 2017-02-08 12:31:13 PST
(In reply to Jim Mathies [:jimm] from comment #4)
> mconley, any sense of priority on this?

Yeah - this is a high-priority one. UX wants this for Photon, but it can go out before Photon is ready.
Comment 6 User image Mike Conley (:mconley) 2017-02-10 07:19:42 PST
Here's phlsa's mock-up of what UX is requesting: https://phlsa.github.io/photon-performance/startup.html

Note that, according to phlsa, it's not necessary (and might not be short-term feasible) to have the content area be rendered even if the browser UI isn't ready. What's most important is for _anything_ (even a blank rectangle) to display and for the icon to appear in the taskbar, immediately once the user starts Firefox.
Comment 7 User image Mike Conley (:mconley) 2017-02-10 13:24:03 PST
One thing that was mentioned in the commentary in https://docs.google.com/document/d/10R8CqOhdcGdkqDJFOQ67vzSiA7aNDinzQLR1OIP4sNI/edit#, but is not part of the mock-up, is that we could show a screenshot of the browser UI in this window while Gecko is still spinning up.

I know there was some concern about showing _content_ that the user might not want displayed from the last shutdown, but we could just show the UI with blank content. We'd need to sort out when to invalidate that screenshot (any time the browser UI changes dimensions or composition, I guess), but I think that is probably strictly better than showing just a blank window.
Comment 8 User image :Harald Kirschner :digitarald 2017-02-10 13:39:38 PST
re: I would experiment with showing hints of UI (wireframe style?), as with themes and addons the final UI could look very different from the default. The other concern is showing anything that might look interactive (but isn't).
Comment 9 User image Mike Conley (:mconley) 2017-02-10 14:18:13 PST
For Windows at least, we need to be processing messages on the native window on the thread that hopes to use that window, in order to make the window paint and to not seem frozen.

Regardless of what we show in that initial window (screenshot, blank, something else), we have a few choices here:

1) Create and show that initial window off of the main thread, but that window will need to be closed / hidden once Gecko is ready and we'll then replace it with an actual Firefox window. I suspect this is probably pretty easy, but is probably not an amazing way to transition is from not running to ready. We might be able to do some sleight of hand to disguise it, but the seams with this approach will probably show a bit no matter what.

2) Create and show that initial window on the main thread, and initialize Gecko _off_ of the main thread. This would allow us to paint that window and make it seem responsive while Gecko starts up. Then, once Gecko is ready, have Gecko "take over" that window, and turn it into a Firefox window.

(2) Is probably the one that'll feel the most "right", and there's actually prior art for this - Metro did something like this back in the day. It is, however, a non-trivial chunk of work to make it work for Desktop-proper. There'd be a lot of plumbing required to do this, and that's not considering any fallout for a11y or other unknown unknowns. jimm estimated this work to be something like 6 months (3 months until we had something we could have something on its feet, the other 3 to deal with potential fallout), and 57 is cut in June (~4 months from today).

So there's some risk with (2). canuckistani, of these two options, do you have a feeling about which one we should place our bet on?
Comment 10 User image Jeff Griffiths (:canuckistani) (:⚡︎) 2017-02-10 14:28:40 PST
(In reply to Mike Conley (:mconley) from comment #9)
> For Windows at least, we need to be processing messages on the native window
> on the thread that hopes to use that window, in order to make the window
> paint and to not seem frozen.
> 
> Regardless of what we show in that initial window (screenshot, blank,
> something else), we have a few choices here:
> 
> 1) Create and show that initial window off of the main thread, but that
> window will need to be closed / hidden once Gecko is ready and we'll then
> replace it with an actual Firefox window. I suspect this is probably pretty
> easy, but is probably not an amazing way to transition is from not running
> to ready. We might be able to do some sleight of hand to disguise it, but
> the seams with this approach will probably show a bit no matter what.

If we go down this road there are some clever things we can do, like make it really obvious that Firefox is still loading and not running yet. This is actually a really old technique, the "loading" dialogue a lot of pro software does ( Pshop, Ableton, various IDEs ). For unavoidably long start times this is much better than the user clicking on the icon, then nothing happens for several seconds, *then* the window appears.

> 
> 2) Create and show that initial window on the main thread, and initialize
> Gecko _off_ of the main thread. This would allow us to paint that window and
> make it seem responsive while Gecko starts up. Then, once Gecko is ready,
> have Gecko "take over" that window, and turn it into a Firefox window.

This would be much better, especially if we could do something, anything in the window before we load Gecko into it.

> (2) Is probably the one that'll feel the most "right", and there's actually
> prior art for this - Metro did something like this back in the day. It is,
> however, a non-trivial chunk of work to make it work for Desktop-proper.
> There'd be a lot of plumbing required to do this, and that's not considering
> any fallout for a11y or other unknown unknowns. jimm estimated this work to
> be something like 6 months (3 months until we had something we could have
> something on its feet, the other 3 to deal with potential fallout), and 57
> is cut in June (~4 months from today).
>
> So there's some risk with (2). canuckistani, of these two options, do you
> have a feeling about which one we should place our bet on?

I think we should go for (2) regardless, I think this is just something we need. The question we're asking is instead, what should we do now, before 57. I think we should do (1) and consider it an opportunity for whimsy injection, assuming the engineering involved is minimal. I think we should investigate (2) and put it in a higher priority backlog, unless someone comes up with a creative solution to (2) where it takes a lot less time.
Comment 11 User image Mike Conley (:mconley) 2017-02-10 15:44:24 PST
I should also mention secret option (3), which is to profile startup and just try to make us start up faster in general so that we don't have to do any of this fake window stuff. But that's filled with a ton of unknowns and I'm not sure how much room there is for improvement.

Also, I made a mistake in comment 9 - 57 isn't cut in June. It's cut in August. That's ~6 months.
Comment 12 User image Mike Conley (:mconley) 2017-02-10 15:51:08 PST
jimm has also expressed an interest in having himself (or his team?) throw some effort into (2) once e10s+a11y is out the door.

Hey canuckistani, I'm a little confused on this bit:

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #10)
> The question we're asking is instead, what should we do now, before
> 57. I think we should do (1) and consider it an opportunity for whimsy
> injection, assuming the engineering involved is minimal.

Assuming we can get some engineers allocated to (2) with a reasonable expectation of having it ship in 57, are you saying we should also try (1) first, either first or in tandem? What did you have in mind for whimsy injection? Some kind of pref-onnable thing that we could drop into a SHIELD study to see if it improves the perceived start-up performance? Or something else altogether?
Comment 13 User image :Ehsan Akhgari 2017-02-13 11:45:12 PST
(In reply to Mike Conley (:mconley) from comment #11)
> I should also mention secret option (3), which is to profile startup and
> just try to make us start up faster in general so that we don't have to do
> any of this fake window stuff. But that's filled with a ton of unknowns and
> I'm not sure how much room there is for improvement.

FWIW I think the last time we actively looked into startup performance was years ago.  I will not be surprised at all if we have grown some low hanging fruit to pick there over the years.
Comment 14 User image Jeff Griffiths (:canuckistani) (:⚡︎) 2017-02-14 08:45:23 PST
(In reply to Mike Conley (:mconley) from comment #12)
> jimm has also expressed an interest in having himself (or his team?) throw
> some effort into (2) once e10s+a11y is out the door.
> 
> Hey canuckistani, I'm a little confused on this bit:
> 
> (In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #10)
> > The question we're asking is instead, what should we do now, before
> > 57. I think we should do (1) and consider it an opportunity for whimsy
> > injection, assuming the engineering involved is minimal.
> 
> Assuming we can get some engineers allocated to (2) with a reasonable
> expectation of having it ship in 57, are you saying we should also try (1)
> first, either first or in tandem? What did you have in mind for whimsy
> injection? Some kind of pref-onnable thing that we could drop into a SHIELD
> study to see if it improves the perceived start-up performance? Or something
> else altogether?

If we go with that assumption, then no. I think 1) should only be pursued if we have low confidence in 2) - sorry for the confusion.
Comment 15 User image Kris Maglione [:kmag] 2017-02-14 12:26:04 PST
(In reply to Mike Conley (:mconley) from comment #7)
> One thing that was mentioned in the commentary in
> https://docs.google.com/document/d/
> 10R8CqOhdcGdkqDJFOQ67vzSiA7aNDinzQLR1OIP4sNI/edit#, but is not part of the
> mock-up, is that we could show a screenshot of the browser UI in this window
> while Gecko is still spinning up.

If we do this, can we please try to make it as clear as possible that the window is not interactive yet, so people don't try to click or type things, and get frustrated when their input gets lost? Or at the lack of rollover effects, and perceived poor responsiveness. This was a common frustration with XUL Fennec, and I'd rather not wind up in that boat again. A soft-focused, or low-detail, screenshot might be enough. Then we could smooth transition into the real UI when it's ready.
Comment 16 User image J. Ryan Stinnett [:jryans] (use ni?) 2017-02-14 12:36:30 PST
(In reply to Kris Maglione [:kmag] from comment #15)
> (In reply to Mike Conley (:mconley) from comment #7)
> > One thing that was mentioned in the commentary in
> > https://docs.google.com/document/d/
> > 10R8CqOhdcGdkqDJFOQ67vzSiA7aNDinzQLR1OIP4sNI/edit#, but is not part of the
> > mock-up, is that we could show a screenshot of the browser UI in this window
> > while Gecko is still spinning up.
> 
> If we do this, can we please try to make it as clear as possible that the
> window is not interactive yet, so people don't try to click or type things,
> and get frustrated when their input gets lost? Or at the lack of rollover
> effects, and perceived poor responsiveness. This was a common frustration
> with XUL Fennec, and I'd rather not wind up in that boat again. A
> soft-focused, or low-detail, screenshot might be enough. Then we could
> smooth transition into the real UI when it's ready.

Some recent sites / apps use a "wireframe" look while things are still loading with filled rectangles where controls and text will soon appear.  Maybe that's useful here with the browser window?

Note You need to log in before you can comment on or make changes to this bug.