Intent to ship: WebRender accelerated SVG filter graphs

[Ashley Hale]

As of Firefox 132, I am turning on hardware accelerated rendering of the most popular SVG filter primitives in WebRender, previously any filter graph of even modest complexity was unaccelerated, causing extreme CPU usage in a large number of situations.  This is controlled by the pref gfx.webrender.svg-filter-effects and has been on by default in nightly since Firefox 130.  This is primarily a performance win on complex filter graphs, but does fix a couple of visual bugs with unusual settings for feComponentTransfer and feColorMatrix.

This pref was enabled in https://bugzilla.mozilla.org/show_bug.cgi?id=1905611 and WPT reftest metadata was updated in https://bugzilla.mozilla.org/show_bug.cgi?id=1918691 for beta simulations that now pass.

[Tom Ritter]

Can you apply these filters on a canvas?  If so, and if this behavior wouldn't respect Canvas' preferences to not use hardware acceleration, this would provide a new vector for fingerprinting via canvas, which is the most prevalent mechanism of fingerprinting presently. (And also one we're working pretty hard to combat.)

The best way to address this would be either to tie the use of hardware into Canvas' preference (which is a bit in flux and also something Kelsey is really the expert on) or to gate it on a RFPTarget [0].  The latter can be done wherever you have a Window or Document reference (usually retained inside a DOM object or accessible during object initialization) doing something like this[1].

-tom

[0] https://searchfox.org/mozilla-central/source/toolkit/components/resistfingerprinting/RFPTargets.inc

[1] https://searchfox.org/mozilla-central/rev/56fd3b43187bca036141c384b809e61d51a447de/dom/xslt/xslt/txEXSLTFunctions.cpp#597

On Wed, Sep 18, 2024 at 10:35 PM 'Ashley Hale' via dev-pl...@mozilla.org <dev-pl...@mozilla.org> wrote:

As of Firefox 132, I am turning on hardware accelerated rendering of the most popular SVG filter primitives in WebRender, previously any filter graph of even modest complexity was unaccelerated, causing extreme CPU usage in a large number of situations.  This is controlled by the pref gfx.webrender.svg-filter-effects and has been on by default in nightly since Firefox 130.  This is primarily a performance win on complex filter graphs, but does fix a couple of visual bugs with unusual settings for feComponentTransfer and feColorMatrix.

This pref was enabled in https://bugzilla.mozilla.org/show_bug.cgi?id=1905611 and WPT reftest metadata was updated in https://bugzilla.mozilla.org/show_bug.cgi?id=1918691 for beta simulations that now pass.

--
You received this message because you are subscribed to the Google Groups "dev-pl...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-platform...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAG1PQQi0fm7JfSZg3Kqa0oBU%2BPhq_g1DeVdHo94%3DAVJrCt1kPw%40mail.gmail.com.

[Ashley Hale]

This does not change anything about filters rendered inside canvas, as that is an entirely different code path unrelated to WebRender (for better or worse we have a lot of code duplication like this).

What this pref changes is the decisions made in Gecko when building WebRender display lists - specifically nsDisplayFilters::CreateWebRenderCommands generates a native WebRender filter chain composed of CSS filters, SVG filters (if this pref is enabled), or goes to software blob fallback.  I think the only relevance to Canvas is that if you wrap a Canvas element in a stacking context you can apply filters to its output with this when it is composed into the page, and this does not change the decision as to whether that is accelerated filters, it only expands WebRender's repertoire of filters so it can handle more complex filter graphs.

If software compositing of canvas into the parent page is desired, code could be added to that function to decide not to accelerate if a child element is an RFP canvas, but I am not sure if that is necessary for RFP purposes, as I thought that the entire displaylist could be software rendered if script asks for an image in that case.