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?)

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?)

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.

s/Not/Note

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

(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" ;).

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

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

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.

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 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.

(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.

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 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 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