- From: Dirk Schulze <vbs85@gmx.de>
- Date: Mon, 19 Apr 2010 11:24:04 +0200
- To: Erik Dahlstrom <ed@opera.com>
- Cc: robert@ocallahan.org, Jasper van de Gronde <th.v.d.gronde@hccnet.nl>, www-svg@w3.org
Am Montag, den 19.04.2010, 11:08 +0200 schrieb Erik Dahlstrom: > On Mon, 19 Apr 2010 10:45:32 +0200, Robert O'Callahan > <robert@ocallahan.org> wrote: > > > On Mon, Apr 19, 2010 at 8:43 PM, Erik Dahlstrom <ed@opera.com> wrote: > > > >> What you are suggesting is to allow the filter primitive subregion to be > >> larger than the filter region, so calling it 'subregion' sounds wrong > >> to me > >> (editorial, but still, if that change is made I'd like to call it > >> 'filter > >> primitive region' instead). > >> > > > > Sounds reasonable. > > > > > >> Regarding clipping to the subregion, is it your opinion then that this > >> clipping should take place on the filter input image, on the filter > >> output > >> image, or both? (For e.g feDisplacementMap this can make quite a > >> difference) > > > > > > The output. > > So if you wanted to clip the filter input image to the subregion you'd > need an additional filter primitive, e.g feOffset, to do it - that may be > undesirable. > > Would being able to control the filter primitive region clipping be > something worth having? E.g a new attribute regionClip = [ input | output > | input-output ]. > > Cheers > /Erik What would be the clipping area? The subregion / effect region of the current primitive? Also what happens if you have two inputs? This problem only appears on the source graphics (SourceGraphic, SourceAlpha, ...). Should we realy add a new attribute to handle this case? Dirk
Received on Monday, 19 April 2010 09:24:43 UTC