Re: [Filter Effects] SVG Filter Regions confusion

On Mar 21, 2013, at 4:01 AM, Stephen White <senorblanco@chromium.org> wrote:

> On Thu, May 24, 2012 at 3:19 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> 
>> 
>> On Thu, May 24, 2012 at 9:05 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> Hi Rik,
>> 
>> please reply to the resend email with the change title. Filter effects belongs to public-fx mailing list.
>> 
>> On May 24, 2012, at 9:49 AM, Rik Cabanier wrote:
>> 
>> > Hi Stephan,
>> >
>> > I agree that the current definition is very confusing. I believe it is also implemented differently across browsers because of this. (Doesn't Opera implement it in a way that people expect, while WebKit does it the 'correct' but hard to figure out way?)
>> You should be really careful with this evidence. I don't promise that WebKit is doing it the right way ;) (I know it isn't on some cases).
>> 
>> >
>> > We have discussed making these parameters optional (or default to auto) so authors don't have to spend a lot of time calculating bounds.
>> We discussed this before but don't have a resolution for that. In general you seem to speak about the filer region it self, not necessarily primitive regions (which are more or less 'auto'). I assume they were set to 120% by default to bound the size of an filter to not get infinite large buffers. It is right that we don't necessarily need filter regions for most effects with the smart behavior of current implementations. And often they limit the web developers a lot. Nevertheless, we have no conclusion how to limit filter effects like lightning or shaders which are potentially infinite large. One suggestion from Roc was to limit them by the ancestor viewport. However, I believe that for developers it would definitely be a benefit to eliminate the default hard clipping filter regions.
>> 
>> Correct. For those filters we don't know the affected region so the author has to calculate this.
>> The new filter primitives already figure out the affected region themselves.
> 
> (Blowing the dust off this thread since this part of the spec is confusing to me as well.)
> 
> When you say "the new filter primitives", do you mean the shorthand filters?

Yes, Rik mixed them together. The shorthands are not filter primitives.

> So those ones automatically determine their filter bounds based on their parameters, while the SVG ones still adhere to the filter effects region. Is that correct?
> 
> If so, then using blur() is supposed to automatically determine the size of its intermediate buffers based on the radius, while feGaussianBlur uses the -10%, -10%, 120%, 120% lacuna values, which may clip its result if the stdDeviation is large enough.  This seems like it would be surprising to users.
> 

Partly correct. The boundaries of shorthands are calculated but the implementation. The user does not need to do anything. In fact, he can not even clip shorthand filters directly.

For SVG Filters we have two clipping regions: the filter region and the subregion. The filter region clips the full filter graph. Every single primitive must be clipped to this global filter region. The default boundaries are the -10%, -10%, 120%, 120%. The subregions clip each filter primitive but cover the filter region by default. However, especially for drop-shadows SVG Filter clip to this boundaries quite often. Since you work on WebKits filter implementation (specifically the Skia implementation) for a longer time, you for sure discovered this already on own experiments.

You are right that this is confusing. My guess that this was done in SVG 1.1 because of two different reasons:
1) to allow more preferment implementations, since the intermediate image buffers are not that big
2) Some primitives can be infinite in size, these have a natural boundaries.

Number 1) is actually not valid. People often make the filter region the size of the whole viewport because they either don't understand filter regions or don't care and let it up to the SVG viewer to optimize. And that is what all implementations do today.
Number 2) is valid.

Erik and I will work are working on an algorithm to calculate smallest boundaries and specify this. We will also try to get a performant way to bound infinite sizes of filter primitives. However, this will not be in the next WD but the one after that.

Greetings,
Dirk

> Stephen 
> 
> Rik
>  
>  
> 
> >
> > I'm unsure if we resolved to make it part of the new FX filters spec…
> >
> > Rik
> >
> > On Wed, May 23, 2012 at 9:30 PM, Stephen Chenney <schenney@chromium.org> wrote:
> > [Re-sending with correct outgoing email.]
> >
> > Dirk,
> >
> > I understand the defaults and how filter subregions are defined. My concern is with how the subregions on the filter effects interact with the filter region (that is, the x,y,width,height on the <filter> element), and how these determine the offscreen image sizes.
> >
> > As I understand the spec, nothing is ever drawn outside the filter region, so that limits the offscreen size. It all seems very clearly defined, apart from the one confusing sentence I originally pointed out. With your response in mind, and some more careful reading, I think the spec is really trying to say:
> >
> > "All intermediate offscreens are defined to not exceed the intersection of ‘x’, ‘y’, ‘width’ and ‘height’ with the filter region, enlarged to include whole pixels that only partly intersect the regions."
> >
> > Stephen.
> >
> > On Wed, May 23, 2012 at 2:06 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> > Hi Stephen,
> >
> > On May 23, 2012, at 7:58 AM, Stephen Chenney wrote:
> >
> > > The SVG 1.1 spec section 15.7.3 says this:
> > >
> > > --------
> > > All intermediate offscreens are defined to not exceed the intersection of ‘x’, ‘y’, ‘width’ and ‘height’ with the filter region. The filter region and any of the ‘x’, ‘y’, ‘width’ and ‘height’ subregions are to be set up such that all offscreens are made big enough to accommodate any pixels which even partly intersect with either the filter region or the x,y,width,height subregions.
> >
> > > --------
> > >
> > > The first sentence explicitly defines the offscreen buffer size to be the intersection of the filter region and the filter effect subregions. The second sentence implies to me that the offscreen buffer size must be the union of the filter region and the filter effect subregions. I'm totally confused.
> > >
> > > Is this just a case of bad phrasing? In particular, the phrase "are made big enough" could be "are big enough"  Is the intention to restrict the valid values of the subregions such that they remain inside the filter region?
> > >
> > > Otherwise, what does it mean?
> >
> > You can define the attributes 'x', 'y', 'width' and 'height' for every filter effect. If you do that, then these values indicate your clipping region. If one of the values is not defined, the clipping region on the missing dimension depends on the union of previous filter effects.
> >
> > For this pseudo example the effect region is the union of the two effects 1 and 2.
> >
> > <feOffset result="1"/>
> > <feOffset result="2"/>
> > <feComposite in="1" in2="2"/>
> >
> > For this pseudo example, the effect is the region defined by the attributes 'x', 'y', 'width' and 'height'.
> >
> > <feOffset result="1"/>
> > <feOffset result="2"/>
> > <feComposite in="1" in2="2" x="0" y="0" width="1" height="1"/>
> >
> > The filter region depends on the union of the input effects for the dimension attributes that are missing.
> >
> >
> > Greetings,
> > Dirk
> >
> > >
> > > Stephen.
> >
> >
> >
> >
> > --
> > Stephen Chenney | Software Engineer | schenney@google.com | 404-314-1809
> >
> >
> >
> 
> 
>

Received on Thursday, 21 March 2013 14:12:54 UTC