search

w3c / svgwg

SVG Working Group specifications
Other
711 stars 133 forks source link

[svg-native] Limited support for filters? #675

Open litherum opened 5 years ago

litherum commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.