W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Re: ISSUE-2223 (filter-bbox): Consider Changing BBox Behavior of Filters [SVG Filters 1.2]

From: Erik Dahlström <ed@opera.com>
Date: Wed, 11 Feb 2009 16:45:01 +0100
To: "SVG Working Group WG" <public-svg-wg@w3.org>
Message-ID: <op.uo611b0lgqiacl@gnorps.linkoping.osa>

On Tue, 10 Feb 2009 22:42:12 +0100, SVG Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:

> ISSUE-2223 (filter-bbox): Consider Changing BBox Behavior of Filters [SVG Filters 1.2]
> http://www.w3.org/Graphics/SVG/WG/track/issues/2223
> Raised by: Doug Schepers
> On product: SVG Filters 1.2
> Mozilla thinks it may be better to let implementations optimize the clipping bbox area of a filter effect by default, rather than requiring the author/tool to specify it.
> http://weblogs.mozillazine.org/roc/archives/2008/02/the_best_of_int.html
> https://bugzilla.mozilla.org/show_bug.cgi?id=467930

Sounds like something to bring up for discussion at the F2F.

I think Mozilla is doing the right thing, and that in this case I believe Inkscape made an error in the calculations.

Batik 1.7, FF3.1b2 and Opera 10 all clip the edges of http://valan.net/tmp/mozilla/clipped_edges_of_blurred_shapes.test.svg.

It is useful in some situations to be able to control the filter region, and to rely on the fact that the UA clips calculations that would otherwise make it slower. Or in other cases to get particular effects applied in the right positions/areas. I think I used both of these techniques in this example[1] (Note that FF3 shows a fallback raster image, due to switching on the requiredFeature http://www.w3.org/TR/SVG11/feature#BasicFilter).

However, I'm thinking that in light of this we might:

- recommend authors to only use the filter regions when necessary for certain effects or for performance reasons
- warn authors that if the filter region is specified edges may get clipped due to the boundingbox not including strokewidth etc
- recommend implementations to optimize the 'userSpaceOnUse' case by calculating a minimal filter region instead of allocating offscreens as large as (or even larger than) the viewport (though it's my understanding that this is fully permitted already, as long as the end result is the same)
- possibly remove the added filter margin attributes that were added in old 1.2 full drafts, and which are now in the filters module (it offers functionality like "make a filter region that is 100% of the bbox and then add 2 pixels")

Having the filter region explicitly specified (when specified correctly) really can make a dramatic difference in performance, at least in Opera 9.x.


[1] http://files.myopera.com/MacDev_ed/blog/vistamenu.svg

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Wednesday, 11 February 2009 15:55:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC