Re: ISSUE-2334 - filter primitive subregion and feGaussianBlur (Was: Re: Announcement: Last Call WD of SVG 1.1 Second Edition)

Erik Dahlstrom wrote:
> ...
> It seems that we have at least four implementations (Opera, Chrome, 
> Batik, Adobe SVG plugin (and I'd assume Illustrator also - untested 
> though)) that conceptually works as "clip the input, apply the filter, 
> clip the output" versus one implementation (Firefox) that conceptually 
> "applies the filter and then clips the output". Inkscape doesn't seem to 
> handle filter primitive subregions (I've tried versions 0.47 and dev-0.48).

I think Inkscape actually handles them in some cases but indeed not for 
gaussian blur. Are there any real-life use cases out there? That 
wouldn't be better off using some kind of mask?

> It can be argued that either way is better or worse (I think that both 
> ways have valid use-cases). Still I'd suggest going with the legacy 
> behaviour (input+output clipping) on this one, and adding a way for SVG 
> Filters 1.2 to say whether input or output clipping is the desired 
> behaviour, e.g by introducing a new filter primitive element feClip.
> 
> Thoughts? Would the above resolution be acceptable to you?

For now I'd say either go with what is done most often or preferably 
what is USED most often (if there are documents out there that use this, 
in what way do they use it). As for the implementation I think 
input+output clipping could be slightly more complicated than just 
output clipping (at least in Inkscape), but not much.

BTW, with regards to SVG Filters 1.2, I would recommend against adding a 
new primitive feClip. As far as I can see clipping is pretty much the 
same as doing an "IN" compositing operation with some fully opaque 
rectangle, except that internally the buffers are supposed to be a 
particular size as well. However, as soon as you do a blur (or 
feMorphology, or feConvolveMatrix, or feDisplacementMap) you have to 
enlarge the buffers again anyway. And adding yet another primitive that 
does more or less the same as a number of other primitives and 
attributes (except that it is not as flexible), definitely does add 
complexity to the implementation.

On the other hand, figuring out that it might be a good idea to reduce 
the buffer size to the intersection of the two buffers when doing 
certain compositing operations is not that difficult (and in most cases 
the performance penalty for not doing probably won't even be that bad). 
You could even add suggestions(!) like this to the specification.

Received on Thursday, 8 July 2010 10:44:00 UTC