[svg-native] Limited support for filters?

[litherum]

Some authoring tools have facilities for shadows or blurs. We should see if we should support those specific use cases without bringing in all the complexity of arbitrary graphs of filters.

[dirkschulze]

Not all graphics libraries provide support for blueing or shadows. Plus: it may require image buffers on rendering again and could be misused easily if no strict restrictions apply (no min/max blur radius). But even those restrictions can get bypassed with a huge amount of scaling.

IMO the risk is higher than the benefit.

[jarek-foksa]

Maybe SVG Native could support the filter property with only some basic standard functions whitelisted such as blur(), drop-shadow() and contrast().

Filters should degrade gracefully when user agent does not support them since they are usually adding minor details or just fine-tuning the graphics. However, from my experience they can easily lock the entire renderer process when misused (even on Chrome / Electron).

[AmeliaBR]

I agree that, if the decision is made to support limited filters, the best way to do that would be through the shorthand functions. The <filter> element could still be prohibited.

But, we'd really need a list of target rendering libraries & which ones we would be excluding by adding blur, etc.

[dirkschulze]

Yes, if supported at all it should just be a set of filter functions.

As said, before, filters require an implicitly or explicitly created off-screen buffer to perform.

• On macOS/iOS there is CoreAnimation and CoreImage that support filters, CoreGraphics does not (with the exception of shadow).
• Skia does have a set of filters that are similarly implemented in Qt, D2D and GDI+ (blur, hue-rotate, contrast, brightness).
• Cairo graphics does not support filter effects.