1825395 - Janky carousel on Apple India home page on Moto G Pure

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Asif Youssuff]

​​### Basic information

Steps to Reproduce:

1. Navigate to https://www.apple.com/in/
2. Wait for page to load
3. Scroll to bottom of page.
4. Use Apple TV+ image carousel and swipe through images, one by one. I went through the entire selection a few times.

Expected Results:

Smooth animation while scrolling through carousel.

Actual Results:

Janky animations. Very obvious compared to Chrome on the same device.

---

Performance recording (profile)

Profile URL:
https://profiler.firefox.com/public/26absq39z01gv0x3bx0fsm9eeznv24nc2wvmh20

System configuration:

OS version: Android 12
GPU model: PowerVR GE8320
Number of cores: Octa-core (4x2.0 GHz Cortex-A53 & 4x1.5 GHz Cortex-A53)
Amount of memory (RAM): 3GB

More information

Singlefile archive for reproducibility: https://drive.google.com/file/d/1_9zroHaJ9jmEHD62JPCeUBbu4C02Zw43/view?usp=share_link

---

Thanks so much for your help.

Comment 1

[Asif Youssuff]

Attachment: about:support

Comment 2

[Alex Thayer [:alexical] (she/her)]

The Performance Impact Calculator has determined this bug's performance impact to be medium. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: Android
Impact on browser: Causes noticeable jank
Impact on site: Causes noticeable jank
Configuration: Specific but common
Websites affected: Major
[x] Affects animation smoothness

Comment 3

[Alex Thayer [:alexical] (she/her)]

Woops. Forgot to include that it's reproducible for me on a Moto G Stylus.

Comment 4

[Sotaro Ikeda [:sotaro]]

:jnicol, can you comment to the bug?

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the Performance Impact field flags this bug as having a high impact on the performance.
:gw, could you consider increasing the severity of this performance-impacting bug? Alternatively, if you think the performance impact is lower than previously assessed, could you request a re-triage from the performance team by setting the Performance Impact flag to ??

For more information, please visit auto_nag documentation.

Comment 6

[Glenn Watson [:gw]]

Seems to be lots of time in the Renderer thread but of course no symbols available in the driver, so it's hard to see what's happening from the profile.

Comment 7

[Jamie Nicol [:jnicol] (on leave until 21st October)]

We actually have a way to sometimes get some more symbols from the driver, but it's a bit fiddly.

Asif, would you please be able to take another profile? This time, with screenshots disabled as they have a bit of overhead. Additionally, if you could go to profiler.firefox.com, open the devtools and click on the "storage" tab. Find "Indexed DB -> https://profiler.firefox.com -> perf-html-async-storage-symbol-tables" in the tree view, right click on it and delete it. Next, find libGLESv2_mtk.so on your device (it's often in /vendor/lib64 or something like that, then run adb pull /path/to/libGLESv2_mtk.so /path/to/local/dir. Then add that directory on your computer that now contains that file to the "Local build" options at the bottom of the profiler settings. Then "save settings and go back" at the top, and finally retake the profile.

On Mali devices this doesn't tend to help at all, but on Adreno it does. Hopefully MediaTek drivers contain the symbols too!

Here's a profile from a Pixel 2 (Adreno 540), where performance isn't great but isn't terrible: https://share.firefox.dev/3zsf8xp

At a quick glance it looks similar to the mediatek profile, time mostly spent in clears and draw calls. This could potentially indicate we're GPU bound.

Comment 8

[Asif Youssuff]

Jamie,

Sorry this took me a while to get to - there wasn't a NI on this for me and even after I saw your request, other stuff got in the way. Hope I followed your instructions correctly.

For anyone else with the same device, libGLESv2_mtk.so is in /vendor/lib/egl, FYI.

Here's the new profile: https://share.firefox.dev/3V00KWY

Thanks!

Comment 9

[Jamie Nicol [:jnicol] (on leave until 21st October)]

Sorry for neglecting this, Asif.

I have run mozregression using fenix builds as they go much further back than geckoview_example. On a high-end device (Samsung S24 or Pixel 8) this used to be perfectly smooth until the 2022-03-23 nightly, when it became quite laggy. That corresponds to these gecko changes. Bug 1760918 jumped out, and sure enough setting layout.animation.prerender.partial to true makes this super smooth on a high-end device. On low or mid end devices that commit made it go from quite laggy (not quite on par with Chrome) to practically unusable.

However, since the bug was filed, this has actually regressed a lot further. Even on high-end devices it is now practically unusable. Bisecting this points to bug 1864425 as the culprit. I filed bug 1891036 for this second regression.

We definitely want to fix the newer regression, and along with fixing up and re-enabling partial prerender (bug 1656473) those will give us our biggest improvements here. I will also continue to investigate to see whether there is anything we improve within webrender

Comment 10

[Jamie Nicol [:jnicol] (on leave until 21st October)]

Hiro, is there any plan to work on re-enabling partial prerender at some point?

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1760918

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Unfortunately no. I don't have any plan to tackle it now and in the near future.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1760918

Comment 14

[Ryan VanderMeulen [:RyanVM]]

So was this fixed by bug 1888748?

Comment 15

[Jamie Nicol [:jnicol] (on leave until 21st October)]

No, 1888748 just made the problem even worse.

Comment 16

[Pascal Chevrel:pascalc]

(In reply to Jamie Nicol [:jnicol] from comment #15)

No, 1888748 just made the problem even worse.

Is that still an S3? Thanks

Comment 17

[Jamie Nicol [:jnicol] (on leave until 21st October)]

Yes it's still an S3

Comment 18

[Frank Doty [:fdoty]]

The severity field for this bug is set to S3. However, the Performance Impact field flags this bug as having a HIGH impact on performance.
:gw, could you consider increasing the severity of this performance-impacting bug? Alternatively, if you think the performance impact is lower than previously assessed, could you request a re-triage from the performance team by setting the Performance Impact flag to ? ?

Would this bug still be considered an S3 given the performance impact? Perhaps :jnicol has some additional insights. If this bug should remain S3 despite the performance impact, can you please provide rationale? Thanks!

Comment 19

[Julien Wajsberg [:julienw]]

I reproduce locally. It's not just the indian website but the main website too. Clearly Firefox is less smooth than Chrome on my Android device.
The calculator still gives a High. Although the "noticeable jank" is only happening on the carrousel at the bottom. So maybe "Medium" wouldn't be wrong. Keeping "High" for now, feel free to change it if you think otherwise.

The Performance Impact Calculator has determined this bug's performance impact to be high. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: Android
Impact on site: Causes noticeable jank
Websites affected: Major
[x] Affects animation smoothness
[x] Able to reproduce locally

Comment 20

[Jamie Nicol [:jnicol] (on leave until 21st October)]

What device are you testing on, Julien? It's really smooth for me on higher end ones, and only noticeably janky on lower end devices. On the lower end devices I tested it's certainly worse than chrome, but chrome isn't smooth either.

It doesn't seem like device power factors in to the performance impact calculator at all, but should it? I also notice apple.com is not listed in the top 50 sites linked to in the calculator. So I don't believe this is an issue that affects the majority of our users. Ticking "reproduces in chrome" in the calculator (which it does to an extent) also reduces the score drastically. I think this should remain an S3.