User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110609 Firefox/7.0a1 Build Identifier: When we load up, we show a black screen with a logo and a piece of text describing basically what's happening. To make this feel like a shorter time, we could be displaying something that's more representative of what will happen. By taking a screenshot on shut-down, we could display that in some way during start-up to give the user a peek at the UI and let them prime themselves for what they're about to do (this may also give the feeling that it takes less time than it does). Reproducible: Always
Created attachment 538823 [details] [diff] [review] Show a screenshot of the last screen during loading This patch is WIP based off of Doug Turner's patch at http://hg.mozilla.org/users/dougt_mozilla.com/wip/raw-file/716102688953/lastscreen_save It screenshots the page at certain points (this should probably just be when the surface is destroyed, the others are likely superfluous) and on start-up, it shows the screenshot low-lit underneath the splash-screen. I also had a further patch that would cross-fade between the splash and the loaded screen, but that needs refinement (it isn't smooth at all, but I like the idea). The art for the splash-screen would need an alpha-transparent background for this to look correct (though maybe this would be a good change anyway, so that it's possible to change the background colour if necessary).
Attachment #538823 - Flags: review?(mbrubeck)
Splash screen visibility is determined by the overall speed of the device and in my case on my Nexus One, I only see the splash screen for about three-four seconds. I don't think showing a picture during this timeframe will be worthwhile or useful for such a short load time. We already exclude slower incompatible devices on the market, so I would imagine with new devices splash screen duration would decrease even moreso.
Comment on attachment 538823 [details] [diff] [review] Show a screenshot of the last screen during loading My main question is how long it takes to save the screenshot, and whether it can/should be done in a separate thread.
Attachment #538823 - Flags: review?(mbrubeck) → feedback+
Assignee: nobody → chrislord.net
Status: UNCONFIRMED → NEW
Ever confirmed: true
What happens if the device orientation changes between shutdown and startup?
(In reply to comment #5) > What happens if the device orientation changes between shutdown and startup? Indeed. There are other philosophical issues I have with this type of feature too. We have been against this type of "make the user think we are faster than we are" trick.
Aaron - on a warm startup, we are no where close to the speed you are talking about. I see Fennec exit all of the time by the system, and startup is in the area of 4-6 seconds. mfinkle - this, couple with fast loading content pages, might give the perception that we are not exiting. I don't think we want to land this feature without having the rest in place.
While I think the style of presentation is worth discussing, I do think that we could be showing something more useful than a black screen with a logo on it - it seems to magnify the impression of waiting. If we can get the time down enough, I would suggest that just a blank screen altogether would be preferable to a splash screen, or a blank screen with a simple spinner and no text/logo. The screenshot idea is nice if we can work on the presentation a bit though. I'll go about timing the time it takes (I don't think it's long, and I think with the suggestion of only doing it when destroying the surface will limit it to only happening when the speed doesn't make a difference to the user) for reference. The screenshot in this patch is always shown centred at the top-middle, so when it's rotated, there is a blank area on either side (or there is a blank area at the bottom and truncation on either side). Perhaps it would be better to save separate screenshots depending on orientation. A further patch I had cross-faded between the splash and the main screen, which looks nice, but I couldn't get it particularly smooth - I may work on this one too (I've had ideas since implementing it that might help).
Doug, how about we do a simple blank UI screenshot? Nothing in URL bar, white page. This works for any sort of startup and we don't have to worry about inconsistencies after we begin painting for real. This is also close to other mobile browsers' behavior.
(In reply to comment #9) > Doug, how about we do a simple blank UI screenshot? Nothing in URL bar, > white page. This works for any sort of startup and we don't have to worry > about inconsistencies after we begin painting for real. > > This is also close to other mobile browsers' behavior. I would actually be OK with this, but where would the image come from? * We could save the image from firstrun, but we lose the ability to show it during the firstrun! * We could ship it with the app, but we would need to worry about various screen sizes and DPI. Using multiple parts of an image would help there, as we could draw the corners and repeat the middle sections.
We have to worry about different themes too. I wonder how hard it would be to set up the blank UI somewhere offscreen and take a snapshot?
(In reply to comment #11) > We have to worry about different themes too. I wonder how hard it would be > to set up the blank UI somewhere offscreen and take a snapshot? That won't work for firstrun, since taking the time to setup the fake UI would be nearly as long as loading the real UI - and if it isn't then it should be. If this is only for post-firstrun, we can use the lastrun startup as the nextrun blank screen.
Instead of taking a screenshot, why don't we construct the screen using the resources the browser xul/css uses? It's not hugely complicated and it doesn't rely on the size of text, so it wouldn't be too huge a deal... We'd probably want to define some mark-up for it, so we can edit it easily and include it as part of the theme, but it seems like a more reliable solution than taking a screenshot (your resolution may change and invalidate your screen, for example - should we take multiple screenshots for orientations/external screens?)
On second thoughts, maintaining mark-up description for the UI would be just as much work as maintaining a screenshot, so that's probably a bad idea. Is the plan to just take a screen on start-up and use that for post-firstrun? If so, do we want to draw it in some particular way (i.e. with 'Loading...' in the url bar and a blank page, or greyed out?)? I'll move ahead on this once we've decided what we're going to do.
Chris, Do you have any ideas on how to get this screenshot for both landscape and portrait modes?
(In reply to Mark Finkle (:mfinkle) from comment #6) > Indeed. There are other philosophical issues I have with this type of > feature too. We have been against this type of "make the user think we are > faster than we are" trick. For the desktop browser, at least, historically that's just not true. ISTR that for a while we had an entire project devoted to making us seem faster. The key metric is not absolute startup speed, but user satisfaction. We measure the former because it's much easier to measure, and it's a proxy for the the latter - but it's not a perfect proxy. We shouldn't lose sight of the difference. Gerv
(In reply to Gervase Markham [:gerv] from comment #16) > (In reply to Mark Finkle (:mfinkle) from comment #6) > > Indeed. There are other philosophical issues I have with this type of > > feature too. We have been against this type of "make the user think we are > > faster than we are" trick. > > For the desktop browser, at least, historically that's just not true. ISTR > that for a while we had an entire project devoted to making us seem faster. That's all well and good. See comment 10 for my current position on this. Smoke and mirrors might help perceived startup time, but real speed improvements are a sure way to get there too. We need to keep working on the real improvements as well. > The key metric is not absolute startup speed, but user satisfaction. We > measure the former because it's much easier to measure, and it's a proxy for > the the latter - but it's not a perfect proxy. We shouldn't lose sight of > the difference. I think we'll find the real startup speed is more closely tied to user satisfaction as well. Faking it has it's own problems. That said, if we come up with a solution that doesn't make matters worse and isn't a complex beast, we should take it.
Created attachment 565595 [details] [diff] [review] updated patch This patch kinda builds on Chris' and kinda on Doug's. It also adds support for portrait / landscape detection. It works like this: * Save a snapshot of the screen where appropriate * Use a filename that has "proptrait" or "landscape" in the name, depending on the current orientation * On startup, use the snapshot for the current orientation, if available * If not available, fallback to the simple, static UI Issues: * The snapshot will show the "Quit" menu if closing via the menu * We don't show the static URL in URLbar if opening a URl from a different app, like Twitter.
I think this snapshot should be limited to when we are restoring session. Not when opening a fresh session.
I'd say this is fixed now - XUL fennec now shows a fake UI, with the target uri in the location bar if there is one, and native fennec starts up fast enough that we don't need a splash.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.