1525420 - Slow performance on https://keithclark.co.uk/labs/css-fps/nojs/

Status: RESOLVED FIXED

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

Description

[Dzmitry Malyshau [:kvark]]

This is a follow-up to the crash issue in https://bugzilla.mozilla.org/show_bug.cgi?id=1522015 , could also be related to another slow-ness bug https://bugzilla.mozilla.org/show_bug.cgi?id=1160130 .

The issue here is to investigate where we are spending time, and what can be done to improve the framerate.

Comment 1

[Dzmitry Malyshau [:kvark]]

Gecko profile: https://perfht.ml/2RDnTwc

Looks like the Renderer thread is the bottleneck here, spending hundreds of milliseconds per frame to composite it. In particular, 1/3 of the thread time is spent in init_fbos() call. This is unexpected: we should preserve the FBOs across frames and only creates new when necessary.

A GPU capture shows us making 355 draw calls, which is more than we should aim for (up to 100, ideally). This happens due to two reasons:

• all the blits necessary for picture caching. If caching is unfeasible here, we should improve the heuristic that disables it, so that blits could be avoided.
• there is a lot of draws of transformed primitives into scissored areas. There are ways to limit the transformed rendering to specific areas without breaking batches, we should look more into it.
• frame is split across 7 passes, which seems a bit high. We need to investigate if the task graph is deeper than needs to be.

Comment 2

[Dzmitry Malyshau [:kvark]]

Apparently, the blits are not due to picture caching, as Glenn noted. They are due to our slow handling of mix-blend modes. See also - https://bugzilla.mozilla.org/show_bug.cgi?id=1519718

Comment 3

[Dzmitry Malyshau [:kvark]]

Crash appears to only occur when picture caching is enabled

Comment 4

[Dzmitry Malyshau [:kvark]]

Attachment: WR don't panic on non-mappable clip rect

Comment 5

[Phabricator Automation]

Comment on attachment 9041820 [details]
WR don't panic on non-mappable clip rect

Revision D18846 was moved to bug 1522015. Setting attachment 9041820 [details] to obsolete.

Comment 6

[Dzmitry Malyshau [:kvark]]

I tested this again with WIP mix-blend rewrite: it feels a bit smoother, but it's not fixed by far. I believe the issues I listed in Comment 1 are still causing the slow.

Comment 7

[Dzmitry Malyshau [:kvark]]

Attachment: Use KHR_blend_equation_advanced for mix-blend mode implementation

Use natively supported mix-blend modes, where appropriate.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/09753a1a153d
Use KHR_blend_equation_advanced for mix-blend mode implementation r=gw

Comment 9

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/09753a1a153d

Comment 10

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

The leave-open keyword is there and there is no activity for 6 months.
:kvark, maybe it's time to close this bug?

Comment 11

[Dzmitry Malyshau [:kvark]]

I don't think so.

Comment 12

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

The leave-open keyword is there and there is no activity for 6 months.
:kvark, maybe it's time to close this bug?

Comment 13

[Jan Alexander Steffens [:heftig]]

Firefox's performance on that page is abysmal, while Chrome is smooth. I think it actually got worse: I vaguely remember it being not nearly as bad.

Comment 14

[Dzmitry Malyshau [:kvark]]

Definitely not closing this then!

Comment 15

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

The leave-open keyword is there and there is no activity for 6 months.
:kvark, maybe it's time to close this bug?

Comment 16

[Jan Alexander Steffens [:heftig]]

Chrome still performs much better than Firefox.

Comment 17

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

The leave-open keyword is there and there is no activity for 6 months.
:kvark, maybe it's time to close this bug?

Comment 18

[Jan Alexander Steffens [:heftig]]

Chrome still performs much better than Firefox.

Comment 19

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

The leave-open keyword is there and there is no activity for 6 months.
:bhood, maybe it's time to close this bug?
For more information, please visit auto_nag documentation.

Comment 20

[Glenn Watson [:gw]]

The graphics performance on this bug seems good to me now, from when I last profiled. I think the remaining issues are event handling related that make it seem like the rendering is slow (see https://bugzilla.mozilla.org/show_bug.cgi?id=1530185). Closing for now, if anyone has a graphics profile that seems particularly slow and is unrelated to the event handling, please open a new bug with details.