1825391 - Janky carousel on Amazon product page on Moto G Pure

Status: NEW

(Core :: Layout, defect)

Description

[Asif Youssuff]

Attachment: OnePlus 11 5G (Eternal Green, 8GB RAM, 128GB Storage) _ Amazon.in_ Health & Personal Care (3_29_2023 2_23_28 PM).html

​​### Basic information

Steps to Reproduce:

1. Navigate to https://www.amazon.in/gp/aw/d/B0BQJLCQD3/ref=mh_s9_acss_cg_Budget_7f1_w?pf_rd_m=A1K21FY43GMZF8&pf_rd_s=mobile-hybrid-11&pf_rd_r=CYK70XSB4Q5PERY52D6J&pf_rd_t=30901&pf_rd_p=1bd530d1-bf5f-4aa9-83da-49dcc8bb3aa7&pf_rd_i=1389401031
2. Wait for page to load
3. Use product 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:

Somewhat janky. Not super noticeable, but very obvious compared to Chrome on the same device.

---

Performance recording (profile)

Profile URL:
https://profiler.firefox.com/public/waz26avhvq84n38r803bz3rmz54vnasb7spn4y0

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 uploaded for reproducibility.

---

Thanks so much for your help.

Comment 1

[Asif Youssuff]

Attachment: about:support

Comment 2

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

Looks like a lot of display list building, so moving to layout(?)

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

[Frank Griffith Jr]

Flagging as S3 given the "medium" performance assessment.

Comment 4

[David Shin[:dshin]]

Pretty inconsistent frame pacing during transitions - There are chains of frames lasting ~50ms and then ~16ms.
Generally, each tick runs over the 60FPS budget, and it seems like we fall into something like:

• Tick
• Another immediate tick
• Wait for paint (Last two paints did not complete)
• Transaction completes, immediate catchup tick
• Repeat

(An aside - curiously, even if the carousel sets a CSS transition property once the touch event is done to snap to an item, I don't see any "Render Reason: ANIMATED_PROPERTY," even on my Pixel 7. My attempt at reproducing the carousel behaviour shows those markers.)

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Probably the transform transition doesn't run on the compositor because the transformed element is wider than the content width.

Comment 6

[David Shin[:dshin]]

Attachment: Testcase to Force Jank on Pixel 7 (Warning: Rapidly Scrolling Colours)

:hiro - looks like that was it, thanks!

Attached testcase makes the animation look a lot jankier on my Pixel 7 (With 90 FPS off).
Should be noted that the reporter's janks seem to come from the compositor not being able to keep up at 60 FPS, but this testcase uses rAF to burn the frame budget.

Without the compositor running to handle animated properties, Frame pacing ends up depending on rAF behaviour. With the animated element's width being sized at 300%, with rAF consistently(-ish) taking ~ 32 [ms], I see some frames towards the start & end of animation lasting twice as long (~60ms). This seems to be noticeable as a little jump. Clicking the button to get the rAF to have inconsistent timing really shows the "judder" caused by less-than-ideal frame pacing.

On the other hand, setting the animated element's width at 100% shows a lot smoother behaviour, since the transition runs on the compositor.

Comment 7

[David Shin[:dshin]]

:emilio informed me about the existence of layout.animation.prerender.partial pref that'd technically allow this animation to run on the compositor. However, enabling this pref unfortunately makes the jank worse, which I imagine is why it got disabled with bug 1760918.
:hiro, do you agree this flag should at least technically improve the behaviour here? If so, is there any planned followup work towards improving/re-enabling it?

Comment 8

[David Shin[:dshin]]

:mstange pointed to bug 1487864 for me, which seems to describe what is going on better (Compositor producing "strange couplets," as content refresh driver waits for compositor to catch up, then immediately overloads it again).
I've filed a separate bug for re: bug 1825391 comment 7: bug 1834065

Comment 9

[Hiroyuki Ikezoe (:hiro)]

I am afraid, I didn't reply within a sane time span. Though I haven't looked the test case in detail, from what I can tell enabling the partial pre-render pref should improve performance in terms of CPU consumption basically. But due to remaining issues for enabling partial pre-render stuff there are some cases that enabling it make animations janky but still CPU consumption gets lower than disabling it.