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