Re: [fxtf-drafts] Clarify the feTile area (#327)

It does look like anyone is correct in the first case - well at least not the way I interpret the spec... In the second case I think the four ones on the right are correct. This could certainly use more tests.
(I made https://jsfiddle.net/oryusfvk/1/ to get some kind of feel for the first case.)

I don't think `feTile` is the problem here though - it seems this is more about filter primitive subregions and/or clipping of outputs.

I'll try to get a motivation down...

First case: `feFlood` generates a 10x10 green square. When used as input to the `feOffset`, this square is clipped against the filter region (per [1]), making the input a 6x6 green square that is shifted down and right by 5 units, and there clipped by its filter primitive subregion (0,0 10x10; inherited from it input) - the result being a 1x1 square (at the "bottom right"). `feTile` then tiles this using `(x + i * width, y + j * height)` (see spec for `feTile`; in short the x,y,width,height reference the input subregion). So we get tile positions (considering the "diagonal" for brevity) as (0, 0), (10, 10), (20, 20), (30, 30)... the contents of each tile being the 1x1 square. Only the tiles that "fall within" the filter primitive subregion of the `feTile` would be rendered though (i and j in [5, 5+10-1] or so). An observation here based on the results presented is that Firefox (and librsvg) seems to tile using the clipped width/height (6) and not the specified (10).

Second case: Here the input to the `feTile` (and `feOffset`) is clipped out by the filter region (being 28,28 144x144) and thus the input tile is fully transparent.

As for "tile start positions" (it has already been covered above), this is determined by the filter primitive subregion of the `feTile` input. I.e the `x` and `y` of the input determine it, making it 0,0 in this case. (It looks like Chrome may have some "drift" here based on the additional test I linked above.)

So I'd say that `feTile` is reasonably clearly defined (perhaps with an exception for the case where clipping happens, but it seems to me that is reasonaly well-defined too?), but maybe not sufficiently tested. Definitely no interop though...

[1] https://drafts.fxtf.org/filter-effects/#FilterPrimitiveSubRegion
> The filter region acts as a hard clip clipping rectangle on the filter primitive’s input image(s).

-- 
GitHub Notification of comment by fsoder
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/327#issuecomment-443506443 using your GitHub account

Received on Sunday, 2 December 2018 13:11:17 UTC