Suspended app screenshots are blurry

[Alan Pope 🍺🐧🐱 🦄]

It's really obvious that an app has been suspended when I switch to it and the screengrab is really blurry. Would be really nice if it wasn't blurry.

See screenshots. One shows blurry clock that I switched to, and then the non-blurry real clock a few seconds later.

[Michał Sawicz (saviq)]

And we should desaturate the screenshot while it's launching and show a spinner after a timeout if the app didn't come up yet.

[Daniel d'Andrada (dandrader)]

It's a half-resolution screenshot to save memory.

[Magdalena Mirowicz (magdalena-mirowicz)]

Why exactly is design assigned to it? It looks like something implementation-related

[Michael Zanetti (mzanetti)]

So the problem is this:

When an app gets killed by a low memory condition, only a screenshot is kept in the right edge spred. If the user then clicks on that screenshot, it is animated to foreground and the app restarted behind the scenes. However, starting an app might take a bit. During this time, the screenshot appears frozen to the user. While presenting a blurred screenshot is not good, I think just adding a full-resolution screenshot isn't good either because the user will try to interact with it.

So we'd need a design on what to do with the screenshot (probably desaturated or something) and if there should be a spinner or something on top of it to indicate that it's loading.

[Albert Astals Cid (aacid)]

unity8 waiting for design -> Incomplete

[Jouni Helminen (jounihelminen)]

I discussed this with Michael and we had the following thoughts

-We should store the screenshots in full res up to some point (like 720p, to be tested when implementing). So on low res devices they are full resolution, on higher dpi devices there won't be that much of a visible diff anyway. Full res screenshots on very high dpi devices is not advisable due to high memory fingerprint

-let's make sure the screenshots are stored as 8bit png's and not 24bit - big memory/size difference and we don't need the alpha channel

-Desaturation and spinner (same way as when starting the app) to indicate state is being restored and the app is not able to respond

-fade out the spinner and have a small crossfade between the desaturated screenshot and the running app in the end if possible

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Matthew Paul Thomas (mpt)]

There are two problems to avoid here.

One is the current problem, where a half-resolution screenshot is in an Uncanny Valley between looking (a) like the actual app or (b) obviously different from the actual app. It ends up looking like a display bug.

If you go for (b), though, you risk a new problem, which is making the phone seem slower than it would seem otherwise. If you see a desaturated screenshot with a spinner just for a couple of seconds, the mere fact that you saw a spinner at all will give you a memory of having had to wait, whereas you might have forgotten one or two taps that did nothing because you were tapping on a screenshot.

One way of reducing this would be to give the app a couple of seconds to resume, then desaturate only if it hasn't. Then give it another couple of seconds to resume, and put up a spinner only if it still hasn't.

[Mateo Salta (mateo-salta)]

yes, we need a "dimed" look to apps that are in this mode.

I always try to click on the screen shot multiple times before it actually loads (even with the low res one...), then you visual see a break while it switches from screenshot to app, so this is really just making things look worse, and people are saying that it is "unresponsive" and "buggy" from this action.

Many times I will swipe away an app that is doing this, assuming it it frozen - then relaunch it new, this is really a bad situation - where the experience of launching an app for the first time is better than resuming...

So, I really think we need to make it clear that apps are in this mode with the dimmed view - then a clean transition to the actual app.