1135804 - [Z3 Leo] Graphical latency during some animations

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[:gerard-majax]

On a Xperia Z3 device (1080p), graphical performances seems to be a bit bad, especially compared to Xperia Z3 Compact running the same build. One specific thing easy to see when playing with the device is the animation visible when tapping the home button and getting back from an app to homescreen. We see some kind of hiccups near the end of the animation.

Looking at framerate did not helped much. Also, video recording do not really make it visible.

Comment 1

[:gerard-majax]

Attachment: Maybe-related parts of logcat

Comment 2

[Mason Chang [Inactive] [:mchang]]

Alexandre thought Silk might be an issue here. I don't have access to the devices, but disabling Silk would give us a good idea if this is a different gfx issue.

Can you please test by setting these three preferences to false:

gfx.vsync.hw-vsync.enabled
gfx.vsync.compositor
gfx.touch.resample

Thanks.

Comment 3

[Mason Chang [Inactive] [:mchang]]

If Silk does make this worse, can you please try a local build with setting this preference to something higher:

https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPrefs.h?from=gfxPrefs.h&case=true#223

Try setting it to 1800. Thanks!

Comment 4

[Sotaro Ikeda [:sotaro]]

Xperia Z3's LCD is full HD(very high resolution). If we use 256*256 tile size in the device, the total number of time becomes huge number, then the performance might be bad compared to Xperia Z3 Compact.

Comment 5

[:gerard-majax]

Thanks for reminding me of this Sotaro, because I already (since two weeks already) have changed the tile size:
> $ cat out/target/product/shinano/system/b2g/defaults/pref/tiles.js 
> pref("layers.tile-width", 360);
> pref("layers.tile-height", 360);

I have felt an improvement, but pushing higher was not providing any visible results.

Comment 6

[:gerard-majax]

(In reply to Mason Chang [:mchang] from comment #2)
> Alexandre thought Silk might be an issue here. I don't have access to the
> devices, but disabling Silk would give us a good idea if this is a different
> gfx issue.
> 
> Can you please test by setting these three preferences to false:
> 
> gfx.vsync.hw-vsync.enabled
> gfx.vsync.compositor
> gfx.touch.resample
> 
> Thanks.

I could not notice any change by toggling those prefs to false.

Comment 7

[Etienne Segonzac (:etienne)]

Not sure it'll help but I remember that when we turned on the FPS counter on both devices, during the same transition, the layer transaction rate (second counter) was strangely high on the z3 compact (~80) but lower than the first counter (~35) on the z3.

Comment 8

[:gerard-majax]

(In reply to Mason Chang [:mchang] from comment #3)
> If Silk does make this worse, can you please try a local build with setting
> this preference to something higher:
> 
> https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPrefs.
> h?from=gfxPrefs.h&case=true#223
> 
> Try setting it to 1800. Thanks!

No noticeable change when pushed to 1800 with silk enabled.

Comment 9

[Mason Chang [Inactive] [:mchang]]

If we can get 2 profiles, one when it is laggy and one when it isn't, that would be very helpful.

Please use this profiling command - ./profile.sh start -p b2g -t Compositor && ./profile.sh start -p Homescreen

Thanks!

Comment 10

[:gerard-majax]

Attachment: Z3 profiling

Comment 11

[:gerard-majax]

Attachment: Z3c profiling

Comment 12

[:gerard-majax]

Here we go :)

Comment 13

[Mason Chang [Inactive] [:mchang]]

Hmm a couple of things about the Z3 profile:

1) Silk looks disabled here, which would cause extra jank. Can you please get another profile with silk enabled on the z3?

2) There is a 130ms rasterize which looks odd. On the Z3 compact, there are a couple more paints that are more than a frame, the compositor is still going. During the 130ms rasterize, there are no composites. I wonder if the animation is OMTA or a main thread animation. You can check by seeing if this loop is ever hit during the animation - https://dxr.mozilla.org/mozilla-central/source/gfx/layers/composite/AsyncCompositionManager.cpp#444

If it's a main thread animation, something else could be going on. It'd be nice to get a layer dump during the animation. In Cleopatra, it has instructions after you upload the profile in the "LayerTree" and "DisplayList" tabs on how to get that information. Getting those would be helpful too.

Comment 14

[:gerard-majax]

Attachment: Z3 profiling with Silk

Comment 15

[Mason Chang [Inactive] [:mchang]]

Hmm, I don't see any paints within the actual profile, which is odd. There is still a ~150ms gap between composites, but I don't see any profile data for the content process and the paint that is there is short enough that it shouldn't cause super extra jank. Vsync timings look fine on the bright side. The composites don't look great but not terrible. Can you try to get another profile so that it has the frame data included with the layer dump and display list please?

Comment 16

[Mason Chang [Inactive] [:mchang]]

Also, could you please just upload the profile to cleopatra and share the link? That would make it a lot easier, thanks!

Comment 17

[:gerard-majax]

Sorry, lots of thing going on. But David just showed me the exact same behavior on his build on Flame

Comment 18

[Johan Lorenzo [:jlorenzo]]

Sorry, I currently don't have any information to provide.

Comment 19

[:gerard-majax]

Enabled slow animations settings, the first time I trigger the issue I do see:
> 03-16 15:11:01.923   292   292 I Gecko   : Performance warning: Async animation disabled because frame size (360, 616) is bigger than the viewport (405, 720) or the visual rectangle (1080, 1849) is larger than the max allowable value (1365) [div with id 'homescreen']

Comment 20

[:gerard-majax]

Indeed, vivien was right. Hacking |maxInAppUnits = aFrame->PresContext()->DevPixelsToAppUnits(4096);| from 4096 to 8192 gets rid of the performance warning, and I have a smooth animation.

Maybe we should avoid hard-coding this and putting it in a pref that we could override per device ?

Comment 21

[Mason Chang [Inactive] [:mchang]]

Hmm, I'm not really sure what's going on, I'm not very aware of this code path. Redirect to :bbirtles.

Hey Brian, any thoughts about comment 20? I think the code in question is here - https://dxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList.cpp#5451

Thanks!

Comment 22

[Brian Birtles (:birtles)]

Yeah, I'm not sure why we set 4096px as the upper bound. Following up with Matt.

Have you tried setting will-change: transform?

Comment 23

[Matt Woodrow (:mattwoodrow)]

Ultimately, we don't want to attempt to retain massive surfaces because it uses a lot of memory.

Also, if we attempt to retain something bigger than the graphics card can handle (max texture size limit), then we'll downscale the retained content by a power of 2 in order to get it to fit.

This is a tradeoff, because we're gaining better performance in exchange for more memory usage, and potentially lower quality rendering. The memory/quality trade-off depends on your GPU, so things that work perfectly for you may look poor for other people.

I believe the b2g email app was setting a transform on the entire email area (massive), so removing this restriction made the app incredibly fast, but the text was downscaled to the point of being unreadable. For this particular app, skipping pre-rendering and rasterizing new content as we scroll was preferable to the low quality.

4906 was chosen as a value that we think most graphics cards should be able to handle within a single texture.

I'm sure we can improve the heuristics here to try get the best outcome in more cases, but it's not entirely trivial, and simply bumping the limit is likely to have unintended consequences.

Comment 24

[:gerard-majax]

I understand it's a memory tradeoff, that's why I relayed the idea from :vingtetun of putting this value in a pref. This way, we could even set it lower on low-memory devices, and we could set it higher on high end devices. For the record, Z3 is 3GB, Z3 Compact is 2GB.

And this is really breaking the very nice and blazing fast UX that this devices have.

Comment 25

[Brian Birtles (:birtles)]

Sorry, this is a graphics question. Matt would be in a much better position than me to judge if this is the right thing to do here.

Comment 26

[Matt Woodrow (:mattwoodrow)]

Having a pref is reasonable, going up to 8192 is pretty scary. That would let us potentially allocate >250mb of VRAM for a single layer. Even if we can allocate those, the initial paint is going to be pretty horrendously slow.

I don't really have time to work on this at the moment though sorry.