From github: https://github.com/mozilla-mobile/fenix/issues/14915.

Steps to reproduce

Browse https://leganerd.com/ on Fenix and scroll.

Expected behavior

Scrolling is smooth.

Actual behavior

Scrolling lags like hell.

Device information

• Android device: Pixel 2 XL, Android 11
• Fenix version: Nightly 200909 06:00 (Build #2015762867), and also stable 80.1.2

Smooth on Chrome

Laggy on Firefox

Profile: https://share.firefox.dev/3ctbqqN

Lots of time spent in texture cache updates. Can reproduce on Mali too.

Can't reproduce on my Linux laptop, however.

Mozregression points to https://hg.mozilla.org/integration/autoland/rev/01ccbe217e03b2942a35a07a5cadeb02213bc73d

It wasn't perfect before that commit, but it was significantly better. Presumably we're now continually evicting something that we weren't before.

This site uses a single giant svg as a spritesheet for all of its icons: https://leganerd.com/wp-content/themes/ln110/i/ln_sprite_100.svg

Even more helpfully, it uses a couple of different background-size values for different icons. There's one element with 465x500 and a few with 1050x1500, meaning that we have to rasterize the SVG twice. That's a 1213x1305 texture and a 2739x3913 texture on my Pixel 2.

Even worse, because of snapping, depending on y scroll position, we sometimes rasterize the 2739x3913 one at 2740x3913. So there's actually 3 of them! (This last part is essentially the same as bug 1398697).

Glenn, it looks to me as if every frame we are evicting at least one of these massive textures, only to reupload it. Do we have some code in the eviction algorithm that should prevent that? Some of the time, this may be because on one frame we request the 2739-height image, so we evict the 2740 to make room. And then the next frame we need the 2740-height image, so evict the 2739 one. But I can also see the 1213x1305 image being continually uploaded, and its height doesn't appear to ever change due to snapping. Any ideas?

Andrew, I wasn't able to find a solution to bug 1398697 back when it was reported. With all your snapping wisdom do you think this is solvable?

If i'm remembering the old whatsapp bug correctly, I think on the gecko side the rasterized images were too big for the image cache, which meant they were being evicted and re-rasterized continually. If that's happening here too, then that might cause webrender to believe they are entirely new images, which would explain the continuos eviction and re-upload.

I think I answered the question for Glenn in comment 4, and in our call it seemed like Andrew was going to take it from here, initially at least.

Hopefully bug 1673653 should fix this

Performance triage: Bug 1664160, a dupe, mentioned we've seen reports of webcompat issues for this site.

I'm unable to reproduce the issue on my Moto G5. I've seen a few issues related to poor scrolling performance on fenix get improved, such as bug 1732817, so I wonder if this has been fixed (or the site changed).

:denschub, are you still able to reproduce the issue (that you originally filed in bug 1664160) or have additional information from webcompat reporters? If not, I wonder if this can be closed (perhaps NI :jnicol).

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

Platforms: Android
Impact on site: Causes noticeable jank
[x] Multiple reporters

(In reply to Michael Comella (:mcomella) [needinfo or I won't see it] from comment #8)

:denschub, are you still able to reproduce the issue (that you originally filed in bug 1664160) or have additional information from webcompat reporters? If not, I wonder if this can be closed (perhaps NI :jnicol).

It seems to be just fine for me now. Let's close this issue, I'm sure we'll get other reports on different sites if there still is an issue. :)