- From: Jasper van de Gronde <th.v.d.gronde@hccnet.nl>
- Date: Sun, 18 Apr 2010 13:41:30 +0200
- To: Dirk Schulze <vbs85@gmx.de>
- CC: robert@ocallahan.org, Erik Dahlstrom <ed@opera.com>, www-svg@w3.org
Dirk Schulze wrote: >> I would suggest grouping and then clipping if the order is the wrong way >> around by default. > But what if you want to filter just a part of the target object, lets > say you want to make a shadow behind a part of an image? BackgroundImage? You draw an object which has the required shape, then use BackgroundImage masked by the filtered object. If you wanted to do it "in-place" you could even blur and then combine the blurred and unblurred images using a mask (all in one filter). More fundamentally, the filter effects region is not MEANT to be a general clipping facility, and is frankly a pretty poor substitute. For example, if you do want to blur (for example) part of the image you would be WAY better off (in most cases) blurring the image first (at least in the appropriate region) and THEN masking. And what if you don't want a rectangular region? Or one that is rectangular, but rotated w.r.t. the local user space coordinates? Obviously there are some cases where it would be pretty complex for a user agent to determine the optimal buffer sizes (and locations), but even in the case I suggested above, where you'd have something like this (omitting some details): ------------------------------------------------------ <filter> <feImage xlink:href="maskingImage" result="mask" /> <feComposite operator="out" in="SourceImage" in2="mask" result="a" /> <feGaussianBlur result="blurred" /> <feComposite operator="in" in="blurred" in2="mask" result="b" /> <feComposite operator="arithmetic" in="a" in2="b" k2="1" k3="1" /> </filter> ------------------------------------------------------ The renderer could relatively easily do something like: ------------------------------------------------------ SourceImage: bbox of filtered object mask: bbox of maskingImage a: SourceImage blurred: SourceImage + margin of 3*stddev b: intersection of mask and blurred output: union of a and b ------------------------------------------------------ If the renderer doesn't want to be smart it can always try to be a bit on the conservative side and still be reasonably efficient most of the time. As it is now Inkscape basically still has to implement most of the logic for doing it right automatically AND has to support clipping to the filter effects region... In view of backwards compatibility it might be problematic to completely ignore the filter effects region in a new SVG standard, and the new margin properties are a definite improvement, but it might not be a bad idea to simply skip adding the new margin properties and add some option that allows a renderer to simply "do the right thing".
Received on Sunday, 18 April 2010 11:42:11 UTC