818765 - Task switcher previews pop in some time after task switcher opens

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Joe Drew (not getting mail)]

When you open the task switcher, you see the name of the tasks (twitter, preferences, etc) for quite some time - probably a full second in some cases - before seeing the previews. It'd be much better if the previews were there upon activating the task switcher.

Comment 1

[David Scravaglieri [:scravag]]

Waiting for massive dogfooders remarks.

Comment 2

[Michael Vines [:m1] [:evilmachines]]

STR:
1) Load up the task switcher with 2-3 apps -- say Contacts, Messages, and Browser
2) Return to homescreen
3) Press'n'hold home button

Takes 500ms-1ms (by my eyeball) for the cards to appear.  This is quite visually jarring.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

The delay in showing the previews comes from capturing new screenshots for each app.

Comment 4

[Andrew Overholt [:overholt]]

David, can you find an owner here?

Comment 5

[Kevin Grandon :kgrandon]

I'm doing some investigation to see if there's anything I can find here. I noticed that the call to frameForScreenshot.getScreenshot can take between 500ms and 2,000ms+.

I don't think it's feasible to keep every image in memory - but we may be able to 'fake' it and keep the current app's screenshot in memory. This would result in the current card's screenshot being shown much quicker, with other apps streaming in after that.

Comment 6

[Kevin Grandon :kgrandon]

I have some ideas for this one..

Comment 7

[Kevin Grandon :kgrandon]

Attachment: Github pull request pointer

Pull request pointer - wondering if you guys could give this a look. I'm still profiling and checking for things that might be bad, but this is working well for me locally. Thanks!

Comment 8

[Justin Lebar (not reading bugmail)]

Right now do we take screenshots from all the apps at once?  Since our device has only one CPU, it would probably make sense to me to take a screenshot of the apps whose cards we're showing before we even start taking the next screenshot.

> I noticed that the call to frameForScreenshot.getScreenshot can take between 500ms and 
> 2,000ms+.

Does it take so long even if you're only running this one getScreenshot() call?

Anyway I don't necessarily object to keeping one screenshot blob in memory; it's compressed and smaller than the full resolution of the screen (right?), so we're not talking about a ton of memory.

I didn't really understand the code, but let me know if you need me to look closely at it.

Comment 9

[Kevin Grandon :kgrandon]

(In reply to Justin Lebar [:jlebar] from comment #8)
> Right now do we take screenshots from all the apps at once?  Since our
> device has only one CPU, it would probably make sense to me to take a
> screenshot of the apps whose cards we're showing before we even start taking
> the next screenshot.

We do take all screenshots at once, but even if we didn't - it would still be slow as a single screenshot can easily take 500ms+.

> Does it take so long even if you're only running this one getScreenshot()
> call?

Yes - I've noticed a single call to getScreenshot() can take ~2k ms or so. Generally they are much faster, but there is the occasional slowdown, and I'm not 100% sure why.

Comment 10

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 716850 [details]
Github pull request pointer

Window manager is keeping first launch screenshots, not current screenshot.

User expect to see the current state of the app in the cards view (unless UX say otherwise).

I also failed to understand what does layer front/back do respectively. So you are using layer front to cover everything until the screenshot loads?

Also, the 150ms is a arbitrary number. It look good on one machine but not the other. Might need to find another way to not to use that, even if that means introducing <img> to replace background-image to get the onload event.

Comment 11

[Kevin Grandon :kgrandon]

Comment on attachment 716850 [details]
Github pull request pointer

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #10)
> Comment on attachment 716850 [details]
> 
> Window manager is keeping first launch screenshots, not current screenshot.
> 
> User expect to see the current state of the app in the cards view (unless UX
> say otherwise).

Hi Tim - As you can see in my code, it keeps the first launch initially, then overwrites it with the current screenshot. This is to achieve fastest performance, and show something besides a blank box to the user immediately.

> I also failed to understand what does layer front/back do respectively. So
> you are using layer front to cover everything until the screenshot loads?
>
> Also, the 150ms is a arbitrary number. It look good on one machine but not
> the other. Might need to find another way to not to use that, even if that
> means introducing <img> to replace background-image to get the onload event.

The two layers are using double buffering to prevent any flicker. This was the only way I found so far. ~150ms is arbitrary, but this generally always looks good to me. (Even if it's not met there's just a small flicker). I'm going to play with alternative solutions, but I'm pretty happy with the current one.

timdream - asking for any feedback here as I'd like to get this landed. Thanks!

Comment 12

[Kevin Grandon :kgrandon]

I did figure out that I can use multiple background images for double buffering instead - this makes the code much cleaner, and response time better.

Comment 13

[Kevin Grandon :kgrandon]

Bug 844245 will track implementing a way to detect full image decoding. Once that has landed, we should be able to remove the setTimeout, but I don't think that should stop this bug from landing.

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 716850 [details]
Github pull request pointer

> Hi Tim - As you can see in my code, it keeps the first launch initially, then
> overwrites it with the current screenshot. This is to achieve fastest
> performance, and show something besides a blank box to the user immediately.

That makes total sense, thanks.

> The two layers are using double buffering to prevent any flicker. This was the
> only way I found so far. ~150ms is arbitrary, but this generally always looks
> good to me. (Even if it's not met there's just a small flicker). I'm going to
> play with alternative solutions, but I'm pretty happy with the current one.

I'll stand-by by my comment about 150ms -- I was explicitly asked by Andreas before not to put something like that in the codebase.

> timdream - asking for any feedback here as I'd like to get this landed. Thanks!

I can give you an f+ here, but please make sure you fix that 150ms later, maybe file a bug about it.

Comment 15

[Kevin Grandon :kgrandon]

Ok, I've updated the comment about the setTimeout, and pointed to bug 844245 which captures the issue.

Once that bug is addressed we should be able to remove the setTimeout.

As this is included in our MWC build, and we've got lots of eyes on it, I've landed it here: https://github.com/mozilla-b2g/gaia/commit/e2d0d82eb3db1509c2d1cb173e0941253c23cc2e

Comment 16

[Michael Vines [:m1] [:evilmachines]]

Requesting uplift to v1.0.1.  This is one of the patches in the MWC build, and results in a dramatic improvement to the perceived quality of task switcher.

Comment 17

[Lukas Blakk [:lsblakk] use ?needinfo]

Marking tef+ so we can get this in v1-train and v1.0.1

Comment 18

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifting commit e2d0d82eb3db1509c2d1cb173e0941253c23cc2e:
v1-train: a8b404d340840e09ec0529910527f5e47372d4ca
v1.0.1: 397a7466f21e7f0c9c82d1527b96e13e24213f02

Comment 20

[Darren]

Issue covered by test case: https://moztrap.mozilla.org/manage/cases/?filter-id=2745

Comment 21

[mdaniloff]

Verified Fixed in Unagi V.1.1 and V.1.0.1:
There is no long delay between when you open the task switcher and the tasks bar

Unagi V.1.1
Unagi Build ID: 20130401070203
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/f9f11b8cbf8a
Gaia: 663101b6eb809383e5882d9bc3868a923a57998a

Unagi build V.1.0.1
Unagi Build ID: 20130401070203
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/b28463f2e718
Gaia: ddb38ac8a34f9e30e09d0ff3b5c1bfb9b664b7c3