1972363 - feImage and feDisplacement results in silent failure

Status: RESOLVED DUPLICATE of bug 1961378

(Core :: SVG, defect)

Description

[snek]

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

Steps to reproduce:

go to https://snek.dev/liquid-glass.html and observe the rounded rectangle.

you can also try changing the feImage's href to https://snek.dev/fedisplacement.png, to show that it is not just an issue with data uris.

Actual results:

the svg filter does nothing.

Expected results:

the svg filter effect is applied. this works in chrome.

Comment 1

[BugBot [:suhaib / :marco]]

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

Comment 2

[Emilio Cobos Álvarez [:emilio]]

FWIW Safari matches us.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

I'm willing to bet https://searchfox.org/mozilla-central/rev/b4412cedce6e2900f5553cbdc43c3fa49c4b9adb/dom/svg/SVGFEDisplacementMapElement.cpp#77 is the culprit or something along those lines.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Ah, no, you're using it on backdrop-filter, and that doesn't support drawing non-GPU-accelerated filters, here:

https://searchfox.org/mozilla-central/rev/b4412cedce6e2900f5553cbdc43c3fa49c4b9adb/layout/painting/nsDisplayList.cpp#8427-8431

So... In theory, there's code to do it, and enabling gfx.webrender.svg-filter-effects.fedisplacementmap and gfx.webrender.svg-filter-effects.feimage should work, however that results in a crash for me: https://crash-stats.mozilla.org/report/index/4644c685-453a-456f-8553-5b5720250616

Ashley, do you know the status of those prefs? I see a lot of the SVG filter effect prefs are turned on by default already.

Comment 6

[Ashley Hale [:ahale]]

Yeah feDisplacementMap and feImage are not implemented fully at this time, respectively they have the following issues:

• feDisplacementMap
  • WebRender side needs work - just needs a bit of shader work, I made an attempt at this but it was not working properly, this filter has been rarely used according to the telemetry I looked at, so I put it at a low priority, tracked as https://bugzilla.mozilla.org/show_bug.cgi?id=1896740 which covers several that are not that hard to implement, but feDisplacementMap probably deserves its own smaller bug because it is very simple.
• feImage
  • Gecko side needs work; where I left on this is that the code needs to retrieve the surface for the image handle, then call the relevant method to send that to WebRender as an ImageKey, I got the impression this would redundantly send the pixel data (which is not great) on every displaylist build, but at least that's still cheaper than blob fallback itself.
  • WebRender side needs work; the shader needs to properly handle the transform matrix and use the chosen filter.

The two of these together is already tracked as https://bugzilla.mozilla.org/show_bug.cgi?id=1896504 but I had not seen an in-the-wild example at that point.

By and large the only truly hard filters to implement is feTurbulence, which sees more usage than you'd expect (despite not being accelerated in any other user agent either).

An extra reason to put effort into these is that HDR rendering won't work with blob fallback.