Implement SVG filter interface for Canvas2D

• Component: Canvas
• Status: RESOLVED INVALID

[Aaron Krajeski]

SVG filters are currently useable in canvas2D but there is no javascript interface for them. WHATWG has recently approved spec changes to this effect:
https://github.com/whatwg/html/issues/5621

Tests are written and can be reviewed and commented upon at:
https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/manual/filters
https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/filters
https://github.com/web-platform-tests/wpt/tree/master/html/canvas/offscreen/filters

Chromium implementation bug: crbug.com/1169216

[Radar WebKit Bug Importer]

<rdar://problem/86770008>

[Philip Jägenstedt]

See also bug 198416, which is about the basic support (string) for the filter attribute. Or at least it was filed before CanvasFilter was added to the spec, so that's a reasonable interpretation of it.

[Thomas Steiner]

I would love to use this in my app SVGcode (https://svgco.de/), since the alternative is to work with dynamically built SVG filter strings (https://github.com/tomayac/SVGcode/blob/ae0a3fbf616afee2accdbfaae1c2d79713f631c7/src/js/preprocess.js#L151-L205), which works if I force this execution path in Chrome, but which fails in Safari (tracked as https://bugs.webkit.org/show_bug.cgi?id=198416#c6). So despite being clumsy, it's not even a working work-around.

Long story short, having the new `CanvasFilter` would make my code a lot easier (https://github.com/tomayac/SVGcode/blob/main/src/js/preprocessworker.js#L89-L113).

[Aaron Krajeski]

@Thomas Steiner

Have you tried in Chrome Canary? The feature is launched there!

[Aaron Krajeski]

(In reply to Aaron Krajeski from comment #4)
> @Thomas Steiner
> 
> Have you tried in Chrome Canary? The feature is launched there!

Never mind! I just re-read your comment. Glad you're using the new feature in Chrome!

[Thomas Steiner]

> Never mind! I just re-read your comment. Glad you're using the new feature in Chrome!

Yeah, I use the new code path by default in Chrome, but what I meant with “forcing” the other code path in Chrome was to artificially fail my feature detection so Chrome takes the Safari/Firefox code path just to verify the approach works in theory (it doesn’t in Safari/Firefox in practice).

[Anne van Kesteren]

Resolving this as INVALID per https://github.com/whatwg/html/pull/7874.