Re: SVG 1.2 filter region extensions

Robert O'Callahan <robert@ocallahan.org> wrote:

ROC> I just discovered
ROC> http://www.w3.org/TR/2007/WD-SVGFilter12-20070501/#filter-margins
ROC>
ROC> I suggest removing this section. The fact is that we already have to
ROC> optimize our offscreen surface sizes by analyzing the filter and the  
target
ROC> object, because authors are producing content with ridiculous filter
ROC> regions. (In particular, Omnigraffle likes to output <filter  
filterUnits="*
ROC> userSpaceOnUse*">, so the filter region for every element contains the
ROC> viewport.) Since we have those optimizations, and I presume all major  
SVG
ROC> user agents will eventually have to follow suit, if they haven't  
already, we
ROC> may as well just let authors specify an absurdly large filter region  
and
ROC> additional facilities for fine-tuning the region will not be useful.
ROC>
ROC> See  
http://weblogs.mozillazine.org/roc/archives/2008/02/the_best_of_int.htmlfor
ROC> a slightly more detailed exposition.

Hello Rob,

It is true that UA:s have a need to handle bad markup such as the case you  
mention. However why would you want to forbid authoring tools from  
generating better svg markup in the future? If viewer UA:s can skip doing  
some additional processing because authoring tools (or authors even)  
produce good markup, then that's a good thing, and authoring tools should  
be encouraged to produce content like that, rather than using  
filterUnits="userSpaceOnUse". This is something authoring tools could  
already avoid doing, even without having SVG 1.2 filters.

In general it's useful to give control to the author, since even if a UA  
does have the kinds of optimizations you talk about there are cases where  
the filter region is smaller than what the UA can effectively estimate.  
And a reduction in the filtered area usually means that the content  
performs better, which should be what people want.

This topic was discussed in a svg-wg telcon, and there was no agreement  
then for removing the filter margins from the spec. However, looking at it  
again I'm not convinced that it needs to be kept in its current form as  
long as the cited use-cases are addressed.

If there was a way of specifying <filter width="100%+2px"  
height="50%+3em"> for example, then the use-cases that filter-margins try  
to cover would be addressed. This is the only thing that the filter  
margins solve currently AFAIK, that you can have both  
objectBoundingBox-relative coordinates and userSpace/absolute coordinates  
at the same time and that they're added up to make the filter primitive  
subregion.

Cheers
/Erik, (ACTION-2018)

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Monday, 30 June 2008 15:53:14 UTC