Re: [filter-effects] Filter primitive subregions and input clipping

I think Chrome and WebKit do clip the input to the filter primitive
subregion. See my fiddle above: in Chrome and Safari, there's a soft grey
edge, indicating that none of the red region has been blended in. In
Firefox, the edge contains red, which indicates to me it's not clipping the
input to FPS.

I'm happy to remove the input clipping if the spec wording does change,
though.

Stephen

On Mon, Nov 3, 2014 at 6:31 PM, Max Vujovic <mvujovic@adobe.com> wrote:

> Hi folks,
>
> I’m wondering why the spec says that filter primitive subregions clip
> their input.
>
> Implementations don’t do it, and I’m struggling to find a benefit of it.
> IMO, we should remove this requirement.
>
> I agree with Stephen White’s statement last time this was discussed [1]:
> "I suppose you could make the argument that if you had only output
> clipping, you could always achieve input-and-output clipping by inserting a
> no-op node (e.g., FEOffset) with the filter primitive subregion set to the
> same values as the child node, e.g.  http://jsfiddle.net/C6zSD/3/.
> Whereas if you have input-and-input clipping, there's no easy way to
> achieve output clipping only."
>
> According to my tests (posted on a related spec bug [2]):
> - Safari, Firefox, and Chrome do not clip the input to a filter primitive
> to its primitive subregion. IE11 was inconclusive; I think I ran into a
> different bug.
> - Safari, Firefox, IE11, and Chrome all clip the input to a filter to its
> filter region.
>
> Thoughts?
>
> Thanks!
> Max
>
> [1]: http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0082.html
> [2]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26432