Task switcher previews pop in some time after task switcher opens

VERIFIED FIXED

Status

Firefox OS
Gaia::System
--
major
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: Joe Drew (not getting mail), Assigned: kgrandon)

Tracking

({b2g-testdriver, polish, unagi})

unspecified
x86
Mac OS X
b2g-testdriver, polish, unagi
Bug Flags:
in-moztrap -

Firefox Tracking Flags

(blocking-b2g:tef+, blocking-basecamp:-, b2g18 verified, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 verified)

Details

(Whiteboard: [MWCDemo2013])

Attachments

(1 attachment)

223 bytes, text/html
Justin Lebar (not reading bugmail)
: feedback+
timdream
: feedback+
Details
(Reporter)

Description

6 years ago
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.
Waiting for massive dogfooders remarks.
blocking-basecamp: ? → -
Keywords: polish
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.
tracking-b2g18: --- → ?
Whiteboard: [MWCDemo2013]
Severity: normal → major
The delay in showing the previews comes from capturing new screenshots for each app.
David, can you find an owner here?
Assignee: nobody → dscravaglieri
Flags: needinfo?(dscravaglieri)
(Assignee)

Comment 5

5 years ago
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.
(Assignee)

Comment 6

5 years ago
I have some ideas for this one..
Assignee: dscravaglieri → kgrandon
Flags: needinfo?(dscravaglieri)
(Assignee)

Comment 7

5 years ago
Created attachment 716850 [details]
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!
Attachment #716850 - Flags: review?(timdream)
Attachment #716850 - Flags: review?(justin.lebar+bug)
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.
Attachment #716850 - Flags: review?(justin.lebar+bug) → feedback+
(Assignee)

Comment 9

5 years ago
(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 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.
Attachment #716850 - Flags: review?(timdream)
(Assignee)

Comment 11

5 years ago
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!
Attachment #716850 - Flags: feedback?(timdream)
(Assignee)

Comment 12

5 years ago
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.
(Assignee)

Comment 13

5 years ago
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 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.
Attachment #716850 - Flags: feedback?(timdream) → feedback+
(Assignee)

Comment 15

5 years ago
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
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
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.
blocking-b2g: --- → tef?
Marking tef+ so we can get this in v1-train and v1.0.1
blocking-b2g: tef? → tef+
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → affected
tracking-b2g18: ? → ---
Uplifting commit e2d0d82eb3db1509c2d1cb173e0941253c23cc2e:
v1-train: a8b404d340840e09ec0529910527f5e47372d4ca
v1.0.1: 397a7466f21e7f0c9c82d1527b96e13e24213f02
status-b2g18: affected → fixed
status-b2g18-v1.0.1: affected → fixed
(Assignee)

Updated

5 years ago
Duplicate of this bug: 837350

Comment 20

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

Comment 21

5 years ago
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
Status: RESOLVED → VERIFIED

Updated

5 years ago
status-b2g18: fixed → verified
status-b2g18-v1.0.1: fixed → verified
You need to log in before you can comment on or make changes to this bug.