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.

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.

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

Crash appears to only occur when picture caching is enabled

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.

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.

Use natively supported mix-blend modes, where appropriate.

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

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

I don't think so.

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

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.

Definitely not closing this then!

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

Chrome still performs much better than Firefox.

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

Chrome still performs much better than Firefox.

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.

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.