808094 - Opening task switcher has unbounded lag

Status: RESOLVED WORKSFORME

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

Description

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

Attachment: Patch to make template app behave badly

STR
 (1) Apply patch to $b2g/gaia
 (2) $ cd $b2g/gaia && make reset-gaia
 (3) Open dialer
 (4) Open Template app (third page of icons)
 (5) Wait for an iteration to go from i->i+1, for example "Iteration 4" -> "Iteration 5"
 (6) Just after that, open the task switcher

After the initial animation, the task switcher UI doesn't appear at all until the template app stops spinning.  Presumably the task switcher is waiting on a screenshot.

This is very very bad for a few reasons
 A. Impossible to have guaranteed responsiveness target; blocks on arbitrary content
 B. While the switcher is hidden, the user will think the task switcher is just broken.  Then it eventually might appear at an unexpected times, which is disturbing.
 C. Broken content can prevent this core UI feature from working at all, for example if it gets stuck in an infinite loop or hits a gecko bug.

I strongly suggest we find a way to avoid unbounded UI lag here.  The solution that ICS seems to use is to show empty placeholders for apps while waiting on its equivalent of screenshots.  That would work great here.

Comment 1

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

I should add, this isn't a theoretical problem, I noticed it last night while playing with some e.me apps.

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Gaia Triage : P3 perf blocker, seems like a reasonable user scenario and people have hit this before.

Comment 3

[Marijn Haverbeke]

I can not reproduce this. After applying the patch and following the steps you describe, I get a fully responsive window manager, and the screenshot for the template app is initially blank (transparent) and then, once the iteration completes, filled in with the current screenshot.

Looking at the code [1] that takes the screenshot, it does seem fully asynchronous -- the callback does nothing more than fill in the background, so the responsiveness of the interface couldn't possibly depend on it.

[1]: https://github.com/mozilla-b2g/gaia/blob/25ae204fdaff2c8e20a67d963cc9198d08a6b834/apps/system/js/cards_view.js#L245

Maybe this was fixed unintentionally? I looked through the git history of the code that I linked, but that doesn't show anything relevant happening recently. Anyway, someone please try to reproduce this again, and see where we stand.

Comment 4

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

Can no longer reproduce.  Looks to have been incidentally fixed.