On Fri, 9 Oct 2015, at 16:27, Vivien Nicolas wrote: > On Thu, Oct 8, 2015 at 6:10 PM, Mounir Lamouri <mou...@lamouri.fr> wrote: > > > Note that Chrome 46 has a way to work around the white screen while a > > page load using a new property in the Manifest. If a website added to > > the homescreen on Chrome Android has a background_color information, it > > will be used while the page loads. After Chrome gets the first paint > > following a non-empty layout, it will remove that plain colour and > > switch to whatever the page has ready. It allows websites to be > > constructed as websites and not rely on that splashscreen feature that > > might or might not be present (given the UA and the current context) and > > also keep the principle of quick first paint. > > > > > Would using a similar system (ie. background_color from the Manifest) > > help you here? > > > > > I will be happy to use the background_color field in the manifest. It > will > likely help web app pinned to the homescreen. > I also think it will be a great idea to use it to replace the static > black > color that is displayed before applications are launched and try to unify > the experience between installed apps and pinned apps. > > However while I think background_color is useful, the white flash we are > trying to address here is between the splash screen and the app content > beeing loaded. I think, but I may be wrong, that we don't want to have a > 3 > steps startup with: > 1. Black splashscreen with icon > 2. plain background_color instead of a white flash > 3. App content beeing displayed when ready. > > I guess 1. and 2. can be merged. > > Now the issue, if my understanding is correct, Gecko does not have the > notion of firstpaint after a non-empty layout. Which means even if 1. and > 2. are merged we can end up in a situation where you have: > 1./2. background_color with/without icon > 3. white flash > 4. App content beeing displayed when ready.
Sorry for misunderstanding. > So basically what I want to add in bug 1211853 (first attachement) is (a > very simple) mechanism to not paint until there is something to paint. > And > from here provide a mechanism for web app to control when first paint > happens without enforcing them to be built a specific way. Did you look into firing the event after there is a non-empty layout or does that come to the same thing as what your patch is doing? Also, it seems unfortunate to have applications hacking around the first paint. As far as speed feeling goes, they would win to show something as soon as possible and handle any post-first paint loading themselves. > An other constraints for application with multi-steps startup is to > display > something as quick as possible to the user and continue their execution > after first paint. As of today there is no way (at least in Gecko, dunno > for Chrome) to know when the UA has painted something on the screen. I > would like to introduce a (moz)firstpaint event so app authors can > optimize > their app to quicly show something on the screen, then wait for the UA to > paint, and then continue their execution. I was talking about a firstpaint even to some Chrome folks earlier this week and I have a TODO to talk with some other folks next week when they will be back from their holidays. So far, the feedback on this idea was fairly positive but I need to make sure there isn't something obvious I'm missing. -- Mounir _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
