- From: Erik Dahlström <ed@opera.com>
- Date: Mon, 30 Jun 2008 17:51:50 +0200
- To: www-svg@w3.org
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