1699261 - [Bug] choppy scrolling on https://www.deutsche-rentenversicherung.de

Status: NEW

(Core :: Graphics: WebRender, defect, P3)

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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

Steps to reproduce

1. Open https://www.deutsche-rentenversicherung.de
2. Scroll down.

Expected behavior

Smooth scrolling

Actual behavior

Choppy scrolling close to the position when the 3 overlay buttons at the bottom start to get shown, and close to the end.

Device information

• Device vendor / model and Android version: Sony Xperia XZ2 Compact
• Firefox for Android version: Nightly 210305, Beta 87.0.0-beta 3, Release 86.1.1 on Android 10

Change performed by the Move to Bugzilla add-on.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I can see something similar on desktop. Maybe it's the same? Here a profile: https://share.firefox.dev/3cN4eXn

There are long wait times for the GPU to finish the previous frame. Maybe rendering some frames take an extra amount of time?

But someone should indeed check on Android.

Comment 2

[Bas Schouten (:bas.schouten)]

Based on at least the desktop profile moving this to graphics for now.

Comment 3

[Jamie Nicol [:jnicol]]

Here's a profile on Android: https://share.firefox.dev/2NEZAlv

Like the profile in comment 1 it shows a lot of time spent in texture upload. Predominately memcpy, indicating the main problem is simply too much texture data being uploaded. Also quite a lot of time in glMapBufferRange. We have an option to use persistently mapped buffers, which could eliminate the glMapBufferRange time. However, we disabled it on Adreno due to bug 1683936. Bug 1684047 tracks re-enabling it for devices unaffected by that driver bug (including this one). However, as things currently stand we still wouldn't recycle this PBO due to it being so large, we currently on recycle PBOs of a certain fixed size. That could be one avenue worth pursuing, however I think our main focus should be reducing the amount of texture data uploaded.

The problem is due to the website's usage of a large SVG as a spritesheet. This is a recurring problem, and bug 1673653 is our intended way to fix this (as it will split the SVG in to tiles, and only the required tiles will be uploaded).

We also evict the item immediately after rendering due to being over the memory usage threshold, which means we are continually uploading and evicting. We've discussed in the past keeping items in the cache when whatever needs them is still on screen (even if we don't need to render it due to picture caching). That might help slightly in this case.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Henrik, do you still see this on desktop?

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:90.0) Gecko/20100101 Firefox/90.0 ID:20210429092605 the choppy behavior is still there when scrolling down to the end of the page.

Comment 6

[Gareth Perks [pexxie]]

Yep, same old story - overly aggressive texture cache eviction.
Found this in bug 1619093. Also noted it in bug 1683354.

My mod that disables the start frame eviction seems to sort it out for me.
See gfx/wr/webrender/src/texture_cache.rs lines 912-917.
It seems like evictions should rather happen at the end of frames - or better; after some idle time - definitely not while animating/rendering.

Original code keeps a very aggressive limit of 32MB for me for "Picture tiles mem".
Disabling the start frame evictions removes this 32MB limit, although "Picture tiles mem" then grows quite big.
I observe this with the pref gfx.webrender.debug.profiler=true.