W3C home > Mailing lists > Public > www-svg@w3.org > April 2010

Re: Margins for filters?

From: Dirk Schulze <vbs85@gmx.de>
Date: Sun, 18 Apr 2010 12:43:06 +0200
To: robert@ocallahan.org
Cc: Jasper van de Gronde <th.v.d.gronde@hccnet.nl>, Erik Dahlstrom <ed@opera.com>, www-svg@w3.org
Message-ID: <1271587386.23486.40.camel@dirk-laptop>

> I challenge you to find one example of real SVG content where the
> author is relying on clipping to the filter region.
Maybe. But at least persons with enough experience use the clipping
rules to make the filterRegion, and therefor the maximal intermediate
buffer size, as small as possible.
And it should still be possible to clip effects. Just imagine that you
want to blur an image (<image filter="...). You may still want exact
edges. Without clipping, they would look washed-out.

> I think it's entirely possible that changing the spec would fix more
> content than it breaks :-).
Indeed. But we can't talk about downward compatibility of SVG 2.0, SVG
Fitler 1.2 and change the complete concept of drawing and calculating a
In WebKit we use the current Specification to make all intermediate
buffer sizes as small as possible. Of course we fail on filterRegions +
all subRegions of the size of the viewPort. We miss some smarter
calculations for these scenarios at the moment.
I won't mourn after the current region concept, but I also won't support
implementing a new concept + current filterRegion/subRegion concept.

To the current margin concept in the draft: It's my opinion, that just
adding an extra unit system and more attributes (mx, my ...) will be
much more confusing for the user. It's a bad choice to rescue the
current filterRegion concept.

Let's say it more clear: Either we live with the current filterRegion
concept or we stand by breaking downward compatibility and implement a
new design that is less confusing for the user.

Received on Sunday, 18 April 2010 10:43:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:26 UTC