OK, let me summarize. We do need some splash screen support due to legacy Tizen support.
Splash screen support needs to be done really well, ie. fade out splash screen, fade in app when done loading etc. This needs to be iOS quality. It probably needs to work with multiple orientations as well. I report on how this works on iOS and other platforms would be useful. @Anssi, do you know if Marcos did some research in this area for the Manifest work? Splash screen (legacy) needs to support the resolutions currently supported by Tizen, but we might need to find out what to do for the future where we want to support all kind of densities, screen sizes etc, for which HTML/CSS is a natural fit. Having Crosswalk preloaded or similar on Tizen would limit the time it takes to load external libraries etc and for non-legacy Crosswalk support, we should not just jump on the splash screen bandwagon without good reason. That means reason enough to convince the W3C SysApps working groups that this is needed. For non-legacy Crosswalk we need to experiment with HTML/CSS splashscreens and developer guidelines. If there is no way we can optimize the start up enough for avoid adding splash screens, we can add them, but then we need to have a nice and good solutions to dealing with multiple screen resolutions/densities and sizes/orientations. Kenneth On Tue, Dec 24, 2013 at 5:45 AM, Zhu, Yongsheng <[email protected]> wrote: >> IMO, it is needed anyway, just because we want people to be able to port >> existing applications with minimal effort, and that includes both ones that >> have a >> 'heavy' first page, and those that already have a splashscreen (for whatever >> reason). > Yes, that's what I want to emphasize. Supporting existing web apps is very > important. > >> > whole. As for the shared process mode, it would benefit Tizen and >> > Linux but I'm not sure for the Android case. so, there is a long way >> > to go, and before everything is optimized and perfect we need a >> > solution for improving user experience. > About the shared process mode, we don't use it so it won't benefit Android > port. > > Yongsheng > > >> -----Original Message----- >> From: Crosswalk-dev >> [mailto:[email protected]] >> On Behalf Of Max Waterman >> Sent: Tuesday, December 24, 2013 10:49 AM >> To: [email protected] >> Subject: Re: [Crosswalk-dev] Intent to implement - SplashScreen API for xwalk >> based application. >> >> On 24/12/13 10:29, Ming, Bai wrote: >> > So, the core idea is that, if we want to drop the support of splash >> > screen, can we guarantee that, no matter how big, how complicated the >> > application is, we can display the 1st screen to user within a >> > acceptable delay. If we can't, the splash screen is definitely needed. >> >> >> IMO, it is needed anyway, just because we want people to be able to port >> existing applications with minimal effort, and that includes both ones that >> have a >> 'heavy' first page, and those that already have a splashscreen (for whatever >> reason). >> >> Max. >> >> >> >> > Though I'm not talking about some bad behaved application that puts >> > everything into the 1st screen, real life cases would be applications >> > that's kind of big, but the 1st screen is relatively simple, so It >> > needs some optimization to make xwalk not loading the application as a >> > whole. As for the shared process mode, it would benefit Tizen and >> > Linux but I'm not sure for the Android case. so, there is a long way >> > to go, and before everything is optimized and perfect we need a >> > solution for improving user experience. >> > >> > - Ming, Bai >> > >> > On 12/24/2013 09:49 AM, Zhu, Yongsheng wrote: >> >> Oh, yes, it's a simple case. The problem becomes severe for real web >> >> apps like games. >> >> For complexity cases, it shows a white screen in several seconds for >> >> some web apps(one user reports 5 seconds for his game). >> >> Specially for Android, since there is no zygote process of crosswalk, >> >> it takes longer time compared to the shared mode on Tizen. >> >> >> >> Yongsheng >> >> >> >> >> >>> -----Original Message----- >> >>> From: Ming, Bai >> >>> Sent: Tuesday, December 24, 2013 9:47 AM >> >>> To: Zhu, Yongsheng >> >>> Cc: [email protected] >> >>> Subject: Re: [Crosswalk-dev] Intent to implement - SplashScreen API >> >>> for xwalk based application. >> >>> >> >>> very simple and basic html page, <body>hello world</hello> that's >> >>> it. no js, no css.. >> >>> One thing we should take into consideration is the shared process mode. >> >>> It can greatly improve the loading speed of an application If enabled. >> >>> >> >>> - Ming, Bai >> >>> >> >>> On 12/24/2013 09:41 AM, Zhu, Yongsheng wrote: >> >>>> Thanks for the data. Which kind of test cases are you using? It >> >>>> depends on the >> >>> complexity of web apps. >> >>>> Yongsheng >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Crosswalk-dev >> >>>>> [mailto:[email protected]] >> >>>>> On Behalf Of Ming, Bai >> >>>>> Sent: Tuesday, December 24, 2013 9:42 AM >> >>>>> To: [email protected] >> >>>>> Subject: Re: [Crosswalk-dev] Intent to implement - SplashScreen >> >>>>> API for xwalk based application. >> >>>>> >> >>>>> I've a done a test several months before for my shared process >> >>>>> mode patch, by loading a simple html hello world page: >> >>>>> current: about 1.5s >> >>>>> shared mode: about <1s >> >>>>> it's on Tizen/PR3 >> >>>>> >> >>>>> - Ming, Bai >> >>>>> >> >>>>> On 12/24/2013 09:26 AM, Wang, Shiliu wrote: >> >>>>>> Creating splashscreen using JS can't cover the period of time >> >>>>>> that xwalk spend >> >>>>> to load native library and resources. Guangzheng/Junmin, could you >> >>>>> provide the data that how long it cost normally? >> >>>>>> Thus, splash screen isn't that user unfriendly, at least it's >> >>>>>> better than a black >> >>>>> screen/white screen at application's startup time. As long as it >> >>>>> keeps for a reasonable time. >> >>>>>> Thanks, >> >>>>>> Shiliu. >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Crosswalk-dev >> >>>>>> [mailto:[email protected]] On >> >>>>>> Behalf Of Kenneth Rohde Christiansen >> >>>>>> Sent: Monday, December 23, 2013 7:34 PM >> >>>>>> To: Waterman, Max >> >>>>>> Cc: <[email protected]> >> >>>>>> Subject: Re: [Crosswalk-dev] Intent to implement - SplashScreen >> >>>>>> API for xwalk >> >>>>> based application. >> >>>>>> I think that is why there should be some max time before initial >> >>>>>> layout finished, >> >>>>> like say 300ms. If the app didn't finish initial layout at that >> >>>>> time the window will show anyway. That way you should have time to >> >>>>> show a simplified UI of your app, or a splashscreen (done with JS >> >>>>> + some background picture etc), and badly behaved apps will still >> >>>>> show up quickly, though their use experience won't be that good. >> >>>>>> Also when creating a splashscreen you most often want it to fade >> >>>>>> nicely into your read UI. That is what happens on iOS and is >> >>>>>> possible to do with creating the splashscreen manually using JS >> >>>>>> and HTML/CSS >> >>>>>> >> >>>>>> On Mon, Dec 23, 2013 at 12:11 PM, Max Waterman >> >>>>>> <[email protected]> >> >>>>> wrote: >> >>>>>>> On 23/12/13 17:50, Kenneth Rohde Christiansen wrote: >> >>>>>>>> A combination of those two methods might be a better solution, >> >>>>>>>> or could at least be researched. >> >>>>>>> IMO, that sounds like a much better solution. >> >>>>>>> >> >>>>>>> Splashscreens always seemed like a bit of a cludge to me - just >> >>>>>>> covering up slowness that should be made faster or removed >> >>>>>>> completely. >> >>>>>>> >> >>>>>>> I do wonder how it would look to a user though - if the app is >> >>>>>>> particularly slow to start, then it will look as if the user >> >>>>>>> hasn't tapped the app icon properly and result in him/her >> >>>>>>> tapping multiple times? >> >>>>>>> >> >>>>>>> Worth looking into, though, for sure. >> >>>>>>> >> >>>>>>> I hope someone is looking into how to minimise the time from the >> >>>>>>> first tap on the app's icon to the app actually starting - imo, >> >>>>>>> that's the real >> >>>>> issue. >> >>>>>>> Max. >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Crosswalk-dev mailing list >> >>>>>>> [email protected] >> >>>>>>> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-d >> >>>>>>> ev >> >>>>>> -- >> >>>>>> Kenneth Rohde Christiansen >> >>>>>> Web Platform Architect, Intel Corporation. >> >>>>>> Phone +45 4294 9458 ﹆﹆﹆ >> >>>>>> _______________________________________________ >> >>>>>> Crosswalk-dev mailing list >> >>>>>> [email protected] >> >>>>>> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-de >> >>>>>> v _______________________________________________ >> >>>>>> Crosswalk-dev mailing list >> >>>>>> [email protected] >> >>>>>> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-de >> >>>>>> v >> >>>>> _______________________________________________ >> >>>>> Crosswalk-dev mailing list >> >>>>> [email protected] >> >>>>> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev >> > >> > _______________________________________________ >> > Crosswalk-dev mailing list >> > [email protected] >> > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev >> >> _______________________________________________ >> Crosswalk-dev mailing list >> [email protected] >> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > _______________________________________________ > Crosswalk-dev mailing list > [email protected] > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆ _______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
