1745050 - https://acko.net/files/slacko/ is very slow when scrolling, much jank

Status: UNCONFIRMED

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

Description

[Gregory Pappas [:gregp]]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

Visit https://acko.net/files/slacko/
Scroll

Actual results:

bad choppy scroll

Expected results:

good smooth scroll

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Botond Ballo [:botond]]

Moving to Performance component for initial investigation.

If you can share a performance profile taken with the Firefox Profiler that would be helpful.

Comment 3

[Gregory Pappas [:gregp]]

(In reply to Botond Ballo [:botond] from comment #2)

Moving to Performance component for initial investigation.

If you can share a performance profile taken with the Firefox Profiler that would be helpful.

https://share.firefox.dev/3oB0bo0

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Janking in the renderer thread -> GFX.
(when tested locally)

Comment 5

[Denis Palmeiro [:denispal]]

I can also reproduce this on Windows. Additional profile: https://share.firefox.dev/3tO8Giz

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:bhood, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Bob Hood [:bhood]]

Glenn, could you please have a look at this?

Comment 8

[Glenn Watson [:gw]]

Attachment: render target allocations

This shows the render target allocations - we can see that each of the 3d segments is allocating quite a large surface, and there are a lot of them.

Comment 9

[Glenn Watson [:gw]]

Attachment: Each segment of the 3d content at the top is a separate render target

Comment 10

[Glenn Watson [:gw]]

There's a few things going on here, all related - this gives us a rough idea why it's janking, but will need some deeper investigation to find the exact cause.

Things to note:

• Each of the 3d elements at the top is a different render target due to the preserve-3d context.

• We are allocating surface sizes much larger than they need to be (this is based on a scale factor estimation of screen size of the element, which can currently overestimate required size, expecially when perspective such as the above is present).

• Since these elements are only rectangles (solid colors), we could actually allocate them to be 16x16 without any quality loss here. We don't currently detect this, and it's a bit of a special case / hack, but it might be worth doing to handle cases like this really well.

• When (smooth) scrolling the number of render targets changes a lot each frame - it may be that we're hitting driver stalls from re-configuring the render target pool each frame.

• There are a number of gfx warnings from the renderer each frame, such as [GFX1-]: Failed to allocate a surface due to invalid size (CDT) Size(0,0) (t=153.261). This is probably due to an edge case where a 3d element is added to the draw lists but ends up clipped or scaled to 0 due to the perspective present.

Fixing one or all of the above issues should resolve the performance problems here.

Comment 11

[Gregory Pappas [:gregp]]

This article explains many implementation details of the site
https://acko.net/blog/making-love-to-webkit/
The Scene Editor seems to cause the same jank present in the site

Comment 12

[Gregory Pappas [:gregp]]

Bug 1764875 improved this significantly (the browser UI itself no longer janks when loading the page, etc.), unfortunately I can't really say the problem is fixed, a very bad jumpiness is still present in the animation. https://share.firefox.dev/3vyPKoq

Comment 13

[Glenn Watson [:gw]]

From a quick look at the most recent profile, it doesn't appear to be GPU related. It looks like there is jank in the content process from JS / layout / DL building. Markus, does that look right to you?

Comment 14

[Markus Stange [:mstange]]

I see some 30ms+ frame building times: https://share.firefox.dev/3kC4g8F
But I agree that the bigger problem is on the main thread. https://share.firefox.dev/3vFA8Q4
Two things that stand out are the large number of samples spent in functions with the word "Matrix", and the time spent in the allocator inside ClipManager::BeginList.