[fx-filter-effects] Behavior of feTile is incompatible between browsers

[smfr]

The rendering of feTile, when the top left tile is partially outside the filter region is not compatible between browsers, and I don't think the spec is clear enough about how it should work.

See:
https://codepen.io/smfr/pen/gowEox

WebKit and Firefox repeat the tile with the size after clipping the top left corner tile.
Blink repeats with the tile size of the input (but the clipping is apparent in the repeated tiles).

I think neither reflect the intent of the spec, which I suspect is to repeat the source in its unclipped form.

[smfr]

@grorg, @svgeesus @AmeliaBR @boggydigital

[AmeliaBR]

Interesting.

The issue is caused by the fact that the filter primitive subregion defined for your <feImage> extends outside the boundaries of the filter region defined for your <filter> element.

Firefox and WebKit are clipping the "filter primitive region" (aka the pattern tile) to the intersection of the two regions.

Chromium and Edge are clipping the image rendering to the filter region, but they are not clipping the pattern tile dimensions. I think this is the closest interpretation of the spec text.

As an author, neither is intuitive, nor particularly useful. Instead, I would want to be able to define an infinitely-repeated texture tile in userSpace, without worrying about whether the reference tile overlaps the bounding box of the current shape. (This is how a <pattern> works.)

feTile definition:

feTile replicates the reference tile in both X and Y to completely fill the target rectangle. The top/left corner of each given tile is at location (x + i*width, y + j*height), where (x,y) represents the top/left of the input image’s filter primitive subregion, width and height represent the width and height of the input image’s filter primitive subregion, and i and j can be any integer value. In most cases, the input image will have a smaller filter primitive subregion than the feTile in order to achieve a repeated pattern effect.

filter primitive subregion definition

All filter primitives have attributes x, y, width and height which together identify a filter primitive subregion which restricts calculation and rendering of the given filter primitive. The x, y, width and height attributes are defined according to the same rules as other filter primitives coordinate and length attributes and thus represent values in the coordinate system established by attribute primitiveUnits on the filter element.

x, y, width and height default to the union (i.e., tightest fitting bounding box) of the subregions defined for all referenced nodes. If there are no referenced nodes (e.g., for feImage or feTurbulence), or one or more of the referenced nodes is a standard input (one of SourceGraphic, SourceAlpha, BackgroundImage, BackgroundAlpha, FillPaint or StrokePaint), or for feTile (which is special because its principal function is to replicate the referenced node in X and Y and thereby produce a usually larger result), the default subregion is 0%, 0%, 100%, 100%, where as a special-case the percentages are relative to the dimensions of the filter region, thus making the default filter primitive subregion equal to the filter region.

If the filter primitive subregion has a negative or zero width or height, the effect of the filter primitive is disabled.

The filter region acts as a hard clip clipping rectangle on the filter primitive’s input image(s).

The filter primitive subregion acts as a hard clip clipping rectangle on the filter primitive result.

All intermediate offscreens are defined to not exceed the intersection of the filter primitive subregion with the filter region. ...

[dirkschulze]

@smfr Would you mind reporting filter effect issues here in the future please? https://github.com/w3c/fxtf-drafts/ Otherwise it is hard to keep track of requests and issue reports.

Edit: Added a reference to this issue inline in the spec.

[dirkschulze]

@smfr @AmeliaBR IMO the relevant sentence is the following:

The filter region acts as a hard clip clipping rectangle on the filter primitive’s input image(s).

Which means that the inputs (feImage here) must be clipped to the filter region before it goes into feTile. Therefore, if I understand the description from @smfr correctly, the behavior of WebKit is following the spec. Blink did have the same behavior as WebKit before. If it changed it likely is a regression.

SVG 1.1 did not specify when clipping should be happening and implementations did it differently. The SVG WG revisited this sentence multiple times and ultimately decided to go with this definition.

[smfr]

I don't think that's what users want, though. As an author I would expect the unclipped image to be tiled.