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. On Thu, Sep 19, 2024 at 6:50 AM Tom Ritter <[email protected]> wrote: > 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 > [email protected] <[email protected]> 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 >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> 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 >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAG1PQQi0fm7JfSZg3Kqa0oBU%2BPhq_g1DeVdHo94%3DAVJrCt1kPw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAG1PQQj1PVPVo4LocqvA6GOWvXkWRrDEBaR1Am4Jo869W9_BXg%40mail.gmail.com.
