1879824 - Codepen demo (https://codepen.io/sschepis/full/wvqzOr) becomes very slow with D2d-canvas

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

[Mayank Bansal]

Use latest Nightly on Windows with D2d-canvas enabled
Go to https://codepen.io/sschepis/full/wvqzOr

AR: The animation becomes very stuttery very quickly.

Regression :

Bug 1871467 - Remove unnecessary CanvasTranslator locking. r=aosmond CLOSED TREE

Differential Revision: https://phabricator.services.mozilla.com/D197112

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

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

Set release status flags based on info from the regressing bug 1871467

:lsalzman, since you are the author of the regressor, bug 1871467, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Bob Hood [:bhood]]

Lee, can we please get Priority/Severity settings applied here?

Comment 4

[Lee Salzman [:lsalzman]]

Attachment: Bug 1879824 - Use aa_stroke_filled_circle in DrawTargetWebgl. r?jrmuizel

WGR is fairly slow at generating specialized circle geometry, whereas we can
generate similar geometry much faster using the AAStroke filled circle
implementation now.

Comment 5

[Phabricator Automation]

Comment on attachment 9380356 [details]
Bug 1879824 - Use aa_stroke_filled_circle in DrawTargetWebgl. r?jrmuizel

Revision D201939 was moved to bug 1880523. Setting attachment 9380356 [details] to obsolete.

Comment 6

[Lee Salzman [:lsalzman]]

Might you please collect a profile so I can see what's going on here?

Comment 7

[Mayank Bansal]

(In reply to Lee Salzman [:lsalzman] from comment #6)

Might you please collect a profile so I can see what's going on here?

https://share.firefox.dev/49B4WT5 / https://share.firefox.dev/3OJ5kHj (gfx logging preset)

Comment 8

[Lee Salzman [:lsalzman]]

In that profile, it's still hitting the DrawTargetD2D1::FillCircle path, so that hasn't really changed, and is what it is as far as performance. The only real overhead I see in the front-end is from the sheer amount of FillCircle requests being submitted in the recording, which is causing us to occasionally block on waiting for buffers here.

Any thoughts, Bob?

Comment 9

[Bob Owen (:bobowen)]

(In reply to Lee Salzman [:lsalzman] from comment #8)

In that profile, it's still hitting the DrawTargetD2D1::FillCircle path, so that hasn't really changed, and is what it is as far as performance. The only real overhead I see in the front-end is from the sheer amount of FillCircle requests being submitted in the recording, which is causing us to occasionally block on waiting for buffers here.

Any thoughts, Bob?

I don't spot anything obvious we can do other that increase the max buffers.
It's an arbitrary figure, but I'm not sure how we would optimize it.

Comment 10

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

Set release status flags based on info from the regressing bug 1871467

Comment 11

[Markus Stange [:mstange]]

(In reply to Mayank Bansal from comment #7)

(In reply to Lee Salzman [:lsalzman] from comment #6)

Might you please collect a profile so I can see what's going on here?

https://share.firefox.dev/49B4WT5 / https://share.firefox.dev/3OJ5kHj (gfx logging preset)

The first profile shows that we're actually spending only 3.5ms per animation update on the main thread. So in theory we can run this animation very quickly.
However, we're updating the screen at a much worse rate.
The page runs the animation from setTimeout. Each individual setTimeout callback is fast.
However, we only update the screen once the refresh driver ticks and submits the main thread frame to the compositor.

The profile shows that the refresh driver ticks occur at a very low rate: https://share.firefox.dev/3UGaqIa (this is the same profile, just a different view into it)
And a lot of the ticks don't submit a paint because a previous paint hasn't been composited yet ("RefreshDriverTick waiting for paint").

So this is a problem with overproduction. If canvas work is added outside of refresh ticks, then the current backpressure mechanism isn't sufficient. So this is basically bug 1831609.

On my machine, I couldn't reproduce the "RefreshDriverTick waiting for paint" problem, instead I see a different reason for slow ticks, which I filed as bug 1881102.