940734 - Keep Scrolling Portion of Settings App as One Layer using will-animate

Status: RESOLVED FIXED

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

Description

[Mason Chang [Inactive] [:mchang]]

Currently the settings app creates a new layer in the scrolling area. We can get some performance wins if we keep the scrollable area in a single layer that stays alive.

Comment 1

[Benoit Girard (:BenWa)]

Adding bug 940842 as a very weak depends of this. i.e. It would be nicer to use this but we shouldn't wait for it at all.

Comment 2

[Mason Chang [Inactive] [:mchang]]

Attachment: settings.patch

Actually a patch developed by Benwa, just attaching here.

Comment 3

[Mason Chang [Inactive] [:mchang]]

Profile before: http://people.mozilla.org/~bgirard/cleopatra/#report=b3acc4738d7e2268ee5e626a34970998678bc435
Profile After: http://people.mozilla.org/~bgirard/cleopatra/#report=18ba27bf2d41e66cb1ce8f95ffdd995f1c8feb19

Looks like we're saving ~1ms per layout paint frame with this patch. We also get a few more instances of layout < 6 ms with this patch. After letting the scroll come to a pause and starting a scroll again (the activity at the end of the profile), we save ~3ms.

Comment 4

[Benoit Girard (:BenWa)]

updated title to make this easier to find.

Comment 5

[Benoit Girard (:BenWa)]

Looks like the profiles we're captured too late and we missed the layer transition. In the profiles where the main thread starts we're painting right from the start. We need to capture a profile where in the before we're idle and the scrolling area doesn't yet have a layer. We should see a non trivial time spent building the layer there.

Comment 6

[Mason Chang [Inactive] [:mchang]]

Here are some profiles in response to Comment 5. I started profiling the pre-allocated app, then loaded the Settings app. I scrolled up and down a bunch of times (the activity in the profiles), then stopped, let the layers flatten out, then scrolled once to measure re layerizing everything (Should be the small peaks at the end). Here are the times for the first 'layout' sections:

without-animate:
13.96
7.64
5.40
6.88
4.60
Total: 38.48

With Animate:
6.84
6.35
6.68
10.12
9.48
Total: 39.47

Then the late scrolls, which is where I stopped, and scrolled once more after the layers should've flattened:
With will-animate: 
21.62
18.78

Without will animate:
17.30
26.14 ms

Full profiles here:
With - http://people.mozilla.org/~bgirard/cleopatra/#report=01ef0e02b04d2106f9404d4b07e6111412210930
Without - http://people.mozilla.org/~bgirard/cleopatra/#report=168ae96f9a1cc488c059a742be5a36c98e58c950

So it looks like at least initially, we can save ~7 ms in layout time and in late scrolls after everything is flattened and we scroll again, we can save ~4.5 ms.

Comment 7

[Mason Chang [Inactive] [:mchang]]

Are these numbers in line with what you were thinking?

Comment 8

[Benoit Girard (:BenWa)]

I was actually aiming for 'Rasterizing' to go down. I'm glad the layout times are also showing an improvement. To be clear we're are interested in the first 1-2 frames, not the rest. From the profiles you link rasterize time goes from 28ms to 8ms. This means we're going to save a dropped frame (nearly two) at the start of pans which is huge for polish :). We're still doing a gralloc allocate and a bit of useless work in the 8ms so I think we can get this down further. But let's focus on will-animate first. The results are very promising indeed :D

Comment 9

[Mason Chang [Inactive] [:mchang]]

Comment on attachment 8337159 [details] [diff] [review]
settings.patch

Review of attachment 8337159 [details] [diff] [review]:
-----------------------------------------------------------------

Per comment

Comment 10

[Mason Chang [Inactive] [:mchang]]

https://github.com/mozilla-b2g/gaia/pull/14282