1891831 - Sluggish scrolling on Android on mastodon.social

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Markus Stange [:mstange]]

On my A54, scrolling https://mastodon.social/ has a latency of 100ms, with composites taking 30ms. Profile: https://share.firefox.dev/445X2zB

The NumDrawCalls markers show a draw call count in the 120-150 range.
Android GPU Inspector shows 100% utilization in the tracks called "Fragment queue utilization", "Fragment utilization", "Full quad warp rate", and "Texture 4x accesses percentage".

The WebRender profiler knows which shaders are taking a long time but I don't know how to read the information; it's just offscreen both in portrait and in landscape mode.

Comment 1

[Markus Stange [:mstange]]

Attachment: WR profiler in portrait mode

Comment 2

[Markus Stange [:mstange]]

Attachment: WR profiler in landscape mode

Comment 3

[Jamie Nicol [:jnicol]]

gfx.webrender.debug.picture-caching shows we're invalidating the whole page every frame whilst scrolling

Despite this, we mostly hit a smooth 60 FPS on a Pixel 2 (Adreno), so I presume there is a Mali-specific issue here causing us to perform so poorly

Comment 4

[Jamie Nicol [:jnicol]]

I have tested on a bunch of devices and it seems to affect all Mali GPUs with a driver version of v1.r38p1 or lower. This happens to be the driver version on my Samsung A54. Interestingly I can reproduce on a Pixel 6a (Mali-G78) and Pixel 7 (Mali-G710) running Android 13, which both have driver version v1.r36p0. Updating those devices to Android 14 bumps the driver versions to v1.r44p0 and v1.r43p0 respectively, which perform much better. So somewhere between r38 and r43 the Mali driver has fixed this issue

Comment 5

[Jamie Nicol [:jnicol]]

The picture caching problem is bug 1829186. The presence of backdrop filter breaks our scroll root detection. We should be able to do better: while the item with the filter must be in the same slice as the filtered item, we should still be able to detect the scroll root properly. This would mean everything that overlaps with the fixed position items would be invalidated during scroll, which is quite a lot of the mastodon page, but better than invalidating literally everything like we currently do. It appears we tried to handle this better in bug 1780320, but it was backed out in bug 1800358 for causing some issues.

Comment 6

[Bob Hood [:bhood]]

Jamie, can you please apply Priority/Severity to this one when you get a chance?

Comment 7

[Jamie Nicol [:jnicol]]

One thing I've noticed about our backdrop filter implementation is that we really get hurt by the presence of multiple backdrop filter items on the same tile. We render the tile without any of said items, then for the first one we blit the portion of the tile to another surface, perform our series of filters, then blit the result back to the tile. Then we repeat for the next backdrop filter item, and so on. We see this on mastodon with the "eye" icons and "ALT" icons that appear on posted images.

I know the Mali best practices doc warns against rendering to the same framebuffer multiple times in a frame, so perhaps that is why we especially struggle on Mali. Perhaps we could detect when the backdrop-filter items do not overlap with each other, then it may be possible to to perform their filter chains in parallel and require fewer passes overall.

Another thing on Mastodon specifically (you'd imagine unlikely to help on too many other sites): the header bar has a backdrop filter but it also has an opaque background colour. I cannot therefore see the backdrop filter having any effect on the page. Perhaps we can elide the backdrop filter in cases such as these.