Re: [Filter Effects] Re: SVG Filter Regions confusion

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? 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.

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
>> >
>> >
>> >
>>
>>
>