957886 - Settings App has Large Chunks of > 100 ms Rasterize causing Jank

Status: RESOLVED WORKSFORME

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

Description

[Mason Chang [Inactive] [:mchang]]

See Profile - https://people.mozilla.org/~bgirard/cleopatra/#report=a9720695c1febb513afcffa3a7f7295d5a57b4b5

This is scrolling the Settings app w/ APZ + HWC enabled. We should find out why we have the large chunks of rasterize time.

Comment 1

[Preeti Raghunath(:Preeti)]

Next steps here??

Comment 2

[Mason Chang [Inactive] [:mchang]]

Still digging.

Comment 3

[Mike Lee [:mlee]]

1.3+: Blocks existing 1.3 blocker Bug 942750: Checkerboarding.

Mason, please update the ETA whiteboard field.

Comment 4

[Mason Chang [Inactive] [:mchang]]

This was a spin off from trying to solve bug 951221. Per https://bugzilla.mozilla.org/show_bug.cgi?id=951221#c15, we're close to 60 FPS and the original bug was closed. While this is still an issue, we don't need it for v1.3. Please make this a non-blocker.

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

Blocking QC CS 1.4, can't leave in the backlog.

Comment 6

[Mason Chang [Inactive] [:mchang]]

Updated profile:

https://people.mozilla.org/~bgirard/cleopatra/#report=257fc1001660f7724d14868f1b9d0723144c5b4f

Comment 7

[Mason Chang [Inactive] [:mchang]]

Attachment: settings_painting.mov

Video of scrolling settings. We don't overpaint a lot, but a bit here and there, especially in the middle sections. I noticed we regressed hard on the layers overpainting. Last time I checked, we were around 300-400, we're up to 500-600. Investigating.

Comment 8

[Mason Chang [Inactive] [:mchang]]

Attachment: Layer Tree while scrolling

Comment 9

[Mason Chang [Inactive] [:mchang]]

Attachment: settingsLayers.mov

Pretty interesting video, every once in a while we see the layer kind of follow the displayport, which would explain the last layer in the layer tree.

Comment 10

[Mason Chang [Inactive] [:mchang]]

I found the following actions bring down the layers from ~500-~600 to ~300.

1) Commenting out all the sections brings us down 100.
2) Removing the grayed out sections such as 'Sim Card' brings us down another layer.
3) Something about the Sim Toolkit operator servers causes another layer.

The following do not affect overpainting:
1) Having the headers removed
2) Removing the form at the bottom of index.html.
3) Taking out the pack switches such as next to airplane mode.

Comment 11

[Mason Chang [Inactive] [:mchang]]

When we bring the layers down to ~350, our painting times drastically drop from 100ms+ down to normal ~350 ish:

https://people.mozilla.org/~bgirard/cleopatra/#report=f6c95518de135733050bbcea434062f45002be1d

Investigating ways to have a full settings app w/ normal layer tree.

Comment 12

[Mason Chang [Inactive] [:mchang]]

Attachment: Layers before and after expensive overpainting

Looking at the layer tree when we do explode while scrolling, 2 things stand out. 

1) The thebes layer after the ref layer goes from non-visible to fully visible. 2) The last container / thebes layer has weird dimensions and an opacity of 0.992, which is odd. Will need to investigate these two things.

Comment 13

[Jason Smith [:jsmith]]

Clearing blocking flag - per a drivers' decision, QC needs to flag individual bugs, not meta bugs, in order to have be CS blockers. We aren't allowing the everything under this meta bug list to be declared as blockers.

Comment 14

[Mason Chang [Inactive] [:mchang]]

Also noticed that the ContainerLayer (0x45cd9800) gets a fixed position, which makes the thebes layer behind it visible. Looking into fixed position CSS.

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

We need this in order to hit the 1.4 goal.

Comment 16

[Mason Chang [Inactive] [:mchang]]

Attachment: Paint Dumping

Another thing I see is that we use the whole 320x480 for just the word 'Settings'. Might be able to optimize that.

Comment 17

[Mason Chang [Inactive] [:mchang]]

I couldn't optimize the layer with the 'Settings' keyword. For testing, I used bug 917416, bug 976299 and disabled APZ and we have 0 overdraw (3rd FPS number). The extra layers w/ APZ come from the displayport growing / shrinking +- 1 viewport as we scroll. Investigating other things to see why we rasterize so much.

Comment 18

[Mason Chang [Inactive] [:mchang]]

Profile up w/ 917416, 976299:

https://people.mozilla.org/~bgirard/cleopatra/#report=64ea0500f3b29e1eacd01c1392831b3908cc1bc4

Looks like we spend a lot of time in the BufferConstructor. I'm wondering, because the displayport size is always changing, we have to reallocate / deallocate the displayport buffer while we scroll, then repaint all the content, which may be causing the large rasterize times.

Comment 19

[Mason Chang [Inactive] [:mchang]]

After talking with :BenWa, we're wasting a lot of time alloc/dealloc displayport buffers as the displayport resizes. Tiling will fix that. With bug 917416 and bug 976299, we've done as much as we can for the settings app. We're pretty optimal w/ sync scrolling. Leaving this open until tiling lands, but nothing actionable.

Comment 20

[Mason Chang [Inactive] [:mchang]]

Another profile,

https://people.mozilla.org/~bgirard/cleopatra/#report=d5c3f963091f5d99937fac82fb0e8273b10fd9c4&search=pgralloc

Looks like we're gated by pgralloc again. Tiling should fix that.

Comment 21

[Mason Chang [Inactive] [:mchang]]

Tested with tiling enabled since it's turned on by default now. Profile:

https://people.mozilla.org/~bgirard/cleopatra/#report=231ac2f5c2de05d2ae02b67aad9637f3877e9f0e

Gecko: 173054:23005b395ae8
Gaia: 6c93da506e79bd7641f2cc0958b531ab84ceefe1

Our largest rasterize times are ~50ms and don't happen very often. I also cannot checkerboard the Settings app no matter how fast I scroll. Awesome stuff with tiling!

Closing this as works for me as all dependent bugs with the settings app have landed and we can't checkerboard.