1767570 - https://nx.dev animation is very slow (SVG filter and animation)

Status: RESOLVED FIXED

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

Description

[709922234]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

visite: https://nx.dev/

Actual results:

animation is very slow

Expected results:

animation is smooth

Comment 1

[709922234]

reason is <header> svg background

Comment 2

[Mayank Bansal]

https://share.firefox.dev/3kBOB9c
The SVG will only animate if the horizontal width of the tab is ~60% of the screen width. Else the animation stops.

Comment 3

[Miko Mynttinen]

A profile from my machine: https://share.firefox.dev/38UZRuU

Seems a bit busy due to animation but nothing obvious stands out.

Comment 4

[Glenn Watson [:gw]]

Wow, we hit what seems to be a very inefficient way to render this content. Perhaps it's expected based on the current implementation, I'm not sure.

I've attached a minimized repro case - there is an HTML file which has a background-image set to a SVG URL. I've reduced the SVG to have a single path (the full case has multiple paths with a gradient and filter).

What appears to happen (I might also just be misinterpreting the call stacks) is:

• We fail to generate WR commands in nsDisplayBackgroundImage, so we create a fallback image.
• That image is rasterized in the content process (lots of time in SkCanvas::drawPath).
• Gecko then decides that this (display item?) should be drawn as a blob.
• The rasterized image from the content process gets serialized as a blob image (lots of time in memcpy under AddBlobImage).
• On the scene building side, we replay the blob (most of the time is spent in the skia blitRect function).

The replay of that blob seems very expensive with the way we tile blobs, but that seems secondary since ideally we wouldn't be drawing the content this way at all?

Jeff / Nical / Andrew, is this expected given the current way we handle blobs?

Comment 5

[Glenn Watson [:gw]]

Attachment: svg-perf.html

Comment 6

[Glenn Watson [:gw]]

Attachment: hero-bg-large.svg

Comment 7

[Glenn Watson [:gw]]

Talking to Jeff, it seems this is unexpected and on his machine this fallback code path is not being hit (and the performance is as expected). It's not clear yet why it differs per machine.

It fails on my machine in https://searchfox.org/mozilla-central/source/image/VectorImage.cpp#785, which then results in the fallback path being hit.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

So this is actually caused by CreateSamplingRestrictedDrawable which we don't use on macOS. We want to stop using it everywhere. Andrew and I or go to come up with a plan next week.

Comment 9

[Glenn Watson [:gw]]

This is much better after https://bugzilla.mozilla.org/show_bug.cgi?id=1746662 landed - there's a bit of time in texture upload, which is expected right now, but it easily runs at 60 fps at 4k for me now.