821554 - Reduce app open transition times

Status: RESOLVED FIXED

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

Description

[Josh Carpenter [:jcarpenter]]

App transitions compete with app loading processes for CPU resources, meaning the longer a transition, the longer the app load will take. Since app load times remain a top performance focus, we can make gains by simply speeding up app transition times. We'll start with the app opening transition.

The relevant code appears to be in two places (per conversation w/ Tim):

* https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/window_manager.js
* https://github.com/mozilla-b2g/gaia/blob/master/apps/system/style/system/system.css

If current transition is approx .5 seconds, we should cut by half, and then evaluate impact on UX (too jarring?) and perf (are gains are noticeable?)

Comment 1

[Josh Carpenter [:jcarpenter]]

Nominating bb+

* Chance to improve performance in key metric
* This is weighted UX-P1 (must fix for release), and has commitment from stakeholders to target for v1 quality improvement.
* Low risk (could be as simple as single CSS value tweak?)

Comment 2

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

Not, bug 780692 looks like it has a very good chance of being uplifted.  However, taking *both* the platform optimization *and* a gaia change that doesn't compromise UX would be fantastic.

Comment 3

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

s/Not/Note

Comment 4

[David Scravaglieri [:scravag]]

We don't block on metabugs, you must create more precise issues for this to depend on.

Comment 5

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

(In reply to David Scravaglieri [:scravag] from comment #4)
> We don't block on metabugs, you must create more precise issues for this to
> depend on.

I don't understand; quoting comment 0

(In reply to Josh Carpenter [:jcarpenter] from comment #0)
> If current transition is approx .5 seconds, we should cut by half, and then
> evaluate impact on UX (too jarring?) and perf (are gains are noticeable?)

I don't think we get more concrete work items than, "cut the current duration in half" ;).

Comment 6

[Josh Carpenter [:jcarpenter]]

Guys, please read the original description. Per Chris, I don't know how we can possibly be any more specific.

Comment 7

[David Flanagan [:djf]]

I worked on that code in window_manager a long, long time ago... taking this.

Comment 8

[David Flanagan [:djf]]

Attachment: link to patch on github

This pull request halves the transition time for each of the transitions in apps/system/style/system/system.css.  

The faster transitions feel really nice to me, except maybe the inline activity transitions might be too fast now.  See what you think, Josh.

Tim, I'm asking for your review because according to the bug, you are the one who pointed out the CSS file that needed to be modified.

Comment 9

[David Flanagan [:djf]]

Josh,

What's the procedure for getting UX-P1 bugs like this landed? Do you have rights to give a+ for this, or do I need to ask Vivien?

Comment 10

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

Comment on attachment 699569 [details]
link to patch on github

r=me. I would worry that somewhere in the System app, a bad dev and a bad review ended up something like

    // wait for the 5 sec app transition
    setTimeout(function() {}, 5000);

but let's not block on the possibility of that and let it break.

Comment 11

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

(In reply to David Flanagan [:djf] from comment #9)
> Josh,
> 
> What's the procedure for getting UX-P1 bugs like this landed? Do you have
> rights to give a+ for this, or do I need to ask Vivien?

My understanding is that the approval process is still the same; however I think that the process will not be sustainable as with the current volume we are overloading Vivien.

Comment 12

[David Flanagan [:djf]]

Thanks Tim.  I just took a quick look through window_manager.js. There are lots of setTimeout() calls, but almost all with no timeout argument.  There's the one in waitForNextPaint that waits 300ms (or 1000ms if the slow transitions debug flag is set).  That doesn't need to be adjusted, does it?

Comment 13

[David Flanagan [:djf]]

Comment on attachment 699569 [details]
link to patch on github

Here's another small one, Vivien. CSS changes only. A UX-P1 bug.

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: apps will feel slower
Testing completed:  works for me!
Risk to taking this patch (and alternatives if risky):

Comment 14

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 699569 [details]
link to patch on github

This one should have been done weeks ago! Thanks for it: https://github.com/mozilla-b2g/gaia/commit/7cecab8eed7d773435d75410fc0013ed955ab457