This is the contingency plan for bug 780692. No one wants apps to just pop in out of the blue, but we're probably going to need either this or bug 780692 to hit startup targets. I'm going to post a baseline patch in a second that we can negotiate up from.

Not a serious patch because it breaks transitions that aren't on the critical startup path. I encourage UX folks to try this out to get a sense of what tradeoffs we're talking about.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #1) > Created attachment 690140 [details] [diff] [review] > Sniffle > > Not a serious patch because it breaks transitions that aren't on the > critical startup path. > > I encourage UX folks to try this out to get a sense of what tradeoffs we're > talking about. I was wondering if some canvas magic can help here? Does 'Faking' the app transition inside a canvas would be cheaper for the CPU?

We caught up on IRC --- canvas would help a little by allowing us to bypass display-list building if we get it right, but I'm afraid we're going to trade one set of problems for another.

Bug 780692 has landed on m-c. If we want to roll with that, should it be blocking-basecamp? Should I aim to land on b2g18 once it has marinated on m-c for a few days?

Yep, commented there. Really really really want to take that :).

UX team discussed our various options based on info from Chris. * Low FPS GIF: we're very skeptical we can make it look good, and we're too short on team hours to pursue long shots. * No animation: a non-starter. Performance optimizations are incredibly awesome in every way, and we'll always try to find ways to reduce unnecessary UX bloat, but there's a line below which we shouldn't fall. People need some dressing with their salad. Eye candy and emotional appeal is what can make products lovable. So our recommendation is to half the transition times, thereby reducing their performance impact (theoretically).

Update: bug 780692 has been approved for uplift, will land soon. That takes overhead of the current animation down to around 100ms on startup. Bug 821554 proposes to cut the duration of the animation in half, which in theory should reduce the startup ding to 50ms. For such an important piece of user feedback, I think that's more than acceptable.

Just did some measurements with gecko d4bf424a67fb1774000435934e144d26cfa4c995 gaia 16006ea0104f6c1518f27bb00e3713ca31b83c5d Starting from a clean flash, I enabled airplane mode in FTU then went through keeping screen on. For reach app, watch for "first real paint" (when my eyes perceive it to load). Load app once and discard result. Then do 5 trials, throw out low/high. For each trial, wait 10 seconds after loading app before closing. Then after closing, wait 5 seconds before relaunching. == base (control: no optimizations) == calculator 1.57, 1.53, 1.63 [discard 1.50, 1.69] dialer 2.81, 2.75, 2.75 [discard 2.72, 2.85] settings 2.53, 2.59, 2.75 [discard 2.50, 3.25] email 5.50, 5.56, 5.50 [discard 5.46, 5.59] == base + disabled animation[1] (control: no animation[1]) == calculator 1.15, 1.15, 1.13 [discard 1.12, 1.16] dialer 2.34, 2.34, 2.41 [discard 2.32, 2.41] settings 2.15, 2.22, 2.25 [discard 2.12, 2.34] email 5.15, 5.12, 5.09 [discard 5.75, 5.00] == bug 780692 + bug 814921 == calculator 1.22, 1.22, 1.22 [discard 1.28, 1.21] dialer 2.34, 2.35, 2.50 [discard 2.22, 2.53] settings 2.19, 2.15, 2.25 [discard 2.13, 2.31] email 5.18, 5.16, 5.15 [discard 4.40, 5.25] == bug 780692 + bug 814921 + bug 821554 == calculator 1.25, 1.28, 1.25 [discard 1.28, 1.13] dialer 2.50, 2.50, 2.38 [discard 2.60, 2.37] settings 2.25, 2.29, 2.25 [discard 2.59, 2.22] email 5.25, 5.19, 5.32 [discard 6.09, 5.18] So domesday - bug 780692 + bug 814921 have the same win for startup as disabling the animation entirely. \o/ - the platform wins *plus* a half-duration animation doesn't help startup. The changes are within noise but the half-duration animation might even hurt a slight bit. Huzzah! [1] "disabled" means, of duration 0.01s. 0.0s didn't work for some reason.

There are some outlier timings for email and settings here that look almost like quantization effects. It'd be interesting to see what might be happening (or not) to quantize.