[GitHub issue by timdream on 2012-08-31T10:54:11Z, https://github.com/mozilla-b2g/gaia/issues/4213] @vingtetun and I talked last night regarding what do we want to do to prevent the opening transitioning screenshot fades to the loading white. There are two ways to handle this problem: - Fade out to the loaded app screen only until we somehow get a event from `<iframe mozbrowser>`. I have no idea whether or not it can be done. @jlebar - Complete change the way how we manage and load our resources in apps. We would probably need a AMD loader that loads heavily stuff one by one in a given sequence, as they are used, or visible. For example, System app now takes disappointing 7 sec to load (it was hidden by me with a black div of Mozilla word mark), if we have a loader to control the loading process, the static HTML can be kept at minimum, and we can at least show the lock screen first. - For most of the apps, with the loader, they can at least show some basic UI and a loading indication. For example, UI tests apps can load the list of tests async from a text file. I suspect most of the time we spent on are to constructing DOM from HTML files. @dzbarsky @cgjones @andreasgal thoughts?

[GitHub comment by cgjones on 2012-08-31T11:04:03Z] We should fade the screenshot out when we get the first MozPaint event from content. We could expose this through the browser API as a "firstpaint" event or something. The last time I measured, one of the biggest startup problems was https://bugzilla.mozilla.org/show_bug.cgi?id=780692 . The b2g master process starves app processes when they're loading, by doing unnecessary work. As we move towards release, we need to be better in apps about lazy loading of resources. Some apps load dozens of JS and stylesheets as they start up, but there's no way all that code/style is needed to display an initial screen. We need to find ways to do this without affecting programmer productivity. Beyond that, we should just profile. We have the ability to do things like https://bugzilla.mozilla.org/show_bug.cgi?id=786818, if that code is "hot" on startup.

[GitHub comment by timdream on 2012-08-31T11:25:50Z] With some tests, I think we should probably do both. 0.7s (faster than the opening transition) seems to be impossible, even for small app like UI tests.

[GitHub comment by timdream on 2012-08-31T11:26:59Z] @cgjones Thanks for the input.

[GitHub comment by jlebar on 2012-08-31T12:27:05Z] File a bug if you want the firstpaint event. We can totally do that, no problem at all. On Fri, Aug 31, 2012 at 8:27 AM, Timothy Guan-tin Chien < notifications@github.com> wrote: > @cgjones <https://github.com/cgjones> Thanks for the input. > > — > Reply to this email directly or view it on GitHub<https://github.com/mozilla-b2g/gaia/issues/4213#issuecomment-8189102>. > >

[GitHub comment by cgjones on 2012-08-31T12:32:10Z] We should get UX to sign off on the transition (CC @jcarpenter ) - load screenshot on startup, slightly grayed out to indicate non-interactivity - keep displayed until firstpaint event from content - fade grayed-out screenshot into real app pixels but the firstpaint event is generally useful enough that we can start that in parallel.

[GitHub comment by timdream on 2012-08-31T13:10:30Z] https://bugzilla.mozilla.org/show_bug.cgi?id=787378 firstpaint bug, thanks @cgjones

[GitHub comment by jcarpenter on 2012-09-04T07:48:04Z] > We should get UX to sign off on the transition (CC @jcarpenter ) > - load screenshot on startup, slightly grayed out to indicate non-interactivity > - keep displayed until firstpaint event from content > - fade grayed-out screenshot into real app pixels Sounds good. The only part that gives me pause is the desaturating the screenshots to indicate inaccessibility. If the average time to firstpaint is less than a second, it could become grating to constantly fade in from gray. The app transition (scale up) might also look odd. I'd say let's give it a shot, assuming the filters are fairly easy to add / remove, and we'll evaluate once we see it in action. I also chatted w/ Tim about this tonight, and he outlined the following: > We are adding "firstpaint" detection in platform, after that: > * For a flash-install first launch, we will not be able to present a loading screen. A dark div will be shown instead. > * At the first paint (i.e. when the html and css is first loaded and the first screen is shown, likely the loading screen of the app itself), we fade out the dark div, and grab the screenshot and save it to the database. > * For running app that is being closed and opens, we animates the current screen of the app > * For all the first launch afterwards (after the user had killed the app and relaunch it, or after phone reboot), we animates the screenshot for the database, and only fades it out after the "firstpaint". A new screenshot will be grabbed in case the app has been upgraded since the previous first launch. > I hope in this way the user will never see the white screen. Overall, sounds great. You guys frigging rock.

[GitHub comment by msandberg on 2012-09-11T17:06:48Z] Just heard of this thread. When you say "screenshot" is that referencing what the app developer might have uploaded in the Marketplace or something else?

[GitHub comment by timdream on 2012-09-11T17:14:52Z] @msandberg No, it's a trick we will use for launching apps in Gaia: save a screenshot of the app if it had ever been launched, and for all following launches, present the user with that screenshot as the web page slowly loads.

[GitHub comment by msandberg on 2012-09-11T17:19:31Z] @timdream great. using an uploaded screenshot would have been bad news bears - the quality tend to differ, to say the least :)

[GitHub comment by AaronMT on 2012-09-11T18:49:21Z] I don't see this mentioned here but there is similar discussions going on with Web Apps in Firefox for Android over in http://bugzil.la/780759; feel free to CC and add thought there too.

[GitHub comment by jcarpenter on 2012-09-19T02:58:02Z] @patrykdesign As per our conversation today, we have free reign over what appears in the temporary loading div, described in my earlier comment, above: https://github.com/mozilla-b2g/gaia/issues/4213#issuecomment-8255007 @timdream Patryk will handle the appropriate visual design treatment for the loading div.

[GitHub comment by autonome on 2012-09-25T06:08:21Z] @patrykdesign what's the ETA for the visual design for this piece?

[GitHub comment by patrykdesign on 2012-09-28T15:15:52Z] @autonome @jcarpenter @timdream I suggest we do the following if a screenshot of the app's state can not be used: 1. Display a "fake" UI splash screen then wait for the app to populate 2. Apps that take too long (3 secs +) or don't use our uniform style use the generic splash screen Graphics: https://www.dropbox.com/sh/zy5a72074nq8xtg/-ACRMZ0SN7

[GitHub comment by timdream on 2012-09-28T16:21:44Z] @patrykdesign Cool, I'll put the generic one into system (make it as default) and put others into each apps as their loading screen.

Tim, where did the screenshot effect get to? What else needs to be done for that part of this work?

Removing a bunch of the labels, since this comes up in every search for every app, and isn't really a take-able bug (yet).

I feel like this bug should be a metabug with one specific bug per app where it needs improvement.

Agreed, done.

Can you guys try removing the transitions and timing how long it takes to load an app? Last time I checked, the app transition animation took a lot of CPU and slowed down startup significantly. I don't suggest this as a permanent fix, but if we know how much of our slow startup is due to the animations, then that indicates how much room there is to improve our startup speed by tweaking the animations.

(In reply to Justin Lebar [:jlebar] from comment #20) > Can you guys try removing the transitions and timing how long it takes to > load an app? > > Last time I checked, the app transition animation took a lot of CPU and > slowed down startup significantly. > > I don't suggest this as a permanent fix, but if we know how much of our slow > startup is due to the animations, then that indicates how much room there is > to improve our startup speed by tweaking the animations. needinfo? myself so I will remember to do this when I have some cycles ...

I tested this on Monday night. Removing the transition saves 0.5s startup time across the board. Bug 780692 has approximately the same effect.

We've got a lot of tracking bugs in relation to start-up. Closing this one in favor of moving to the other one.