|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
59 bytes, text/x-review-board-request
|Details | Review|
Bug 1378688 - Scale the image to save APK size, respect channel, and hide splash screen when the user interact with url bar.
59 bytes, text/x-review-board-request
|Details | Review|
The app used to load the UI and then the web page, which gave the impression it was busy loading the web page. Now it loads the splash screen with the Firefox logo as the app icon, which I see regularly. Overall, this gives the feeling of a much slower app. Instead of attempting to load the web page, it appears it's now struggling to just load itself. Adding "regression" since this is a UX regression in the area of perceived performance.
Maybe it might feel better if most of the splash screen (save for example a small circular area immediately surrounding the logo) was transparent, so you could still see the actual UI starting up and pretending to load the page (even if it is in fact still starting up Gecko). But generally I agree - the current splash screen implementation just makes things feel slower.
This change also increased the size of the fennec apk by about 350k: == Change summary for alert #7808 (as of July 11 2017 03:57 UTC) == Regressions: 1% installer size summary android-4-0-armv7-api15 opt 36,200,098.58 -> 36,544,662.00 For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=7808
I just filed 1380008 for the APK size issue, thanks wlach!
Comment on attachment 8885172 [details] Bug 1378688 - Make Splash Screen faster by making it's background transparent. https://reviewboard.mozilla.org/r/156034/#review161514
Attachment #8885172 - Flags: review?(max) → review+
I'm concerned that showing any kind of splash icon will reduce perceived performance. We want to give the impression that Firefox is always ready instantly, even if the web page is not. Does this new approach result in the application UI being fully visible? That will give the feeling that Firefox is always snappy and responsive.
Actually, if we're showing the application UI fully rendered, then why show the application icon at all? Instead could show a loading animation in the viewport. I think that would result in better perceived performance, and tells a more truthful story about all the various reasons things might be slow in loading/rendering the *web page*, as distinct from the *application*.
Another interesting optimization could be to show a loading animation and then once the favicon of the website is available, show that in the animation somehow. That tells an even clearer story about what's being slow.
[triage@0712] Nevin is working on it. +
Hi Dietrich! Thanks for your feedback! I've submit a new version. Please help check in Nightly after it lands:)
Duplicate of this bug: 1378175
Duplicate of this bug: 1380008
Duplicate of this bug: 1376579
We need to be careful about loading animations. In the past we've seen that those can be very costly in terms of battery life, and in some cases they can slow down the actual page load. I'll see if I can dig up some bugs from years back.
https://bugzilla.mozilla.org/show_bug.cgi?id=917896#c1 and related bugs for reference
Comment on attachment 8885652 [details] Bug 1378688 - Scale the image to save APK size, respect channel, and hide splash screen when the user interact with url bar. https://reviewboard.mozilla.org/r/156474/#review161894 ::: mobile/android/base/java/org/mozilla/gecko/widget/SplashScreen.java:7 (Diff revision 1) > +import android.util.Log; > +import android.view.View; Not secessary import?
Attachment #8885652 - Flags: review?(max) → review+
Hi snorp I totaly agree with you about the CPU usage. And even memory consumtion( We scale the logo image to reduce the APK size). This will increase ~8MB memory footprint when startup. But at this time I think the hardware spec is much better now. I'll still want to see how the users repsonse to our design for "perceived performance".
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/29ab214f96d2 Make Splash Screen faster by making it's background transparent. r=maliu https://hg.mozilla.org/integration/autoland/rev/7b5d4791c970 Scale the image to save APK size, respect channel, and hide splash screen when the user interact with url bar. r=maliu
(In reply to Nevin Chen [:nechen] from comment #25) > I'll still want to see how the users repsonse to our design for > "perceived performance". Hey Nevin, do you have any background on why we added the splash screen to begin with? I'm pretty skeptical that showing a Firefox logo will improve perceived performance in any way. I think it does the opposite. It tells a clear story about how *Firefox* is slow, instead of how the *network or website* is slow.
I'm curious, maybe Snorp you know this: Do we have telemetry around how often we get launched from app icon vs link click? I filed this bug because my use of the browser feels almost entirely from app-to-app, not homescreen launches, which made the splash screen feel especially intrusive in the workflow. I can understand the Firefox logo splash on launch from homescreen. But when loading from other app, seems like we want to do everything possible to instantly launch app UI and push any perceived slowness away onto other potential causes.
AFAIK the splash screen is just a resource and thus is displayed while the system is trying to load the UI. However Fennec takes longer than your average Android app to load the UI due to using custom UI elements. I'm not sure if that'll be negated after Photon.
(In reply to Paul [pwd] from comment #30) > AFAIK the splash screen is just a resource and thus is displayed while the > system is trying to load the UI. However Fennec takes longer than your > average Android app to load the UI due to using custom UI elements. While Gecko does unfortunately indeed need a few seconds to get up and running, the rest of our UI actually appears fairly quickly. There's only a short flash of white (which by the way is still there even with the splash screen) before we show the address bar (complete with the progress bar pretending we're already loading the page, even if in fact we're still busy starting up Gecko first), and once that happens you can already interact with the app in some ways, e.g. open/close tabs, look at the awesome screen, paste a link to open it, etc. Hence the splash screen (especially the current variety on Nightly with the all white background) makes things feel slower, because now it seems like even our UI is taking several seconds to start up.
(In reply to Dietrich Ayala (:dietrich) from comment #29) > I'm curious, maybe Snorp you know this: Do we have telemetry around how > often we get launched from app icon vs link click? We do record telemetry on this, but I don't really know how to find the results. https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#4293
Status: NEW → RESOLVED
Last Resolved: 11 months ago
status-firefox56: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 56
Filed a follow-up to re-examine the logo issue; bug 1380698
status-firefox54: --- → unaffected
status-firefox55: --- → unaffected
Verified that the URL bar and loading indicator are now visible on Nightly 57 and Beta 56 and the screen closes if you interact with the URL bar.
Status: RESOLVED → VERIFIED
status-firefox56: fixed → verified
status-firefox57: --- → verified
QA Contact: oana.horvath
You need to log in before you can comment on or make changes to this bug.