Steam developer announcements overlay is janky/stuttery to scroll
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
9.90 MB,
video/mp4
|
Details |
STR:
- In Firefox for Android, visit https://store.steampowered.com/app/1966720/Lethal_Company/
- Scroll down to "recent events & announcements" and tap the middle of the tile to open up the announcements in an overlay.
- Scroll the announcements up/down.
ACTUAL RESULTS:
Scrolling is extremely stuttery and janky.
EXPECTED RESULTS:
No such jank; regular scrolling experience.
Chrome gives expected-results here, on the same device.
I'm using Firefox Nightly 133.0a1 2024-10-27 on a Pixel 6a running Android 15.
This reproduces regardless of whether the dynamic toolbar is enabled, so it's not related to that.
Here's a profile with Firefox Nightly presets (so that there's a screenshot track enabled:
https://share.firefox.dev/3YFmrit
Here's a profile with Graphics presets:
https://share.firefox.dev/3UsVE6G
In the Graphics track, there are a lot of "Composite" marker-bars that are fairly long, on the order of 20-30ms, sometimes 40+ms, e.g. here we've got two ~42ms composites back-to-back: https://share.firefox.dev/4e3AqDq
(I'm assuming this belongs in WebRender given that's where we seem to be spending cycles, but feel free to reclassify if needed.)
Reporter | ||
Updated•10 months ago
|
Reporter | ||
Updated•10 months ago
|
Reporter | ||
Comment 1•10 months ago
•
|
||
Here's a screencast of the experience in Firefox (at the start of the video) vs. Chrome (at the end of the video). (This screencast doesn't quite do it justice; I think some of the jitter may've been smoothed out in video compression / frame-rate limitations or somesuch).
The jank is most-noticeable for short slow scroll operations, where I just give my screen a gentle nudge. As the scroll slows down to a stop, there's some noticeable stuttering & inconsistent frame-rate.
Comment 2•10 months ago
•
|
||
Could it be the known slowness of backdrop-filter on some android devices? (some steps in bug 1891831)
Reporter | ||
Comment 3•10 months ago
|
||
Could definitely be related. Poking in devtools, I didn't immediately see a usage of backdrop-filter
on these elements, but I did see filter
being used.
Comment 4•10 months ago
|
||
We'll find somebody who can reproduce this and investigate.
Updated•10 months ago
|
Comment 5•10 months ago
|
||
Taking this out of triage since Jamie is available to look at it.
Comment 6•10 months ago
|
||
This is indeed due to the backdrop filter. The header bar of each update card has one. This isn't as catastrophic as bug 1891831 where many backdrop filterered items are on the same picture cache tile causing an explosion in the number of render passes. But it does still increase the number of passes somewhat. And as described in bug 1829186 completely prevents picture caching from working effectively.
Description
•