Bug 136482 – Filters have weird clipping on compositing tile borders

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: CSS

[Dirk Schulze]

On compositing tiles, filters are clipped and refiltered. This has really strange effects on gaussian blur filters. See the example at http://codepen.io/adobe/pen/eJHgl move the slider for the bottom iframe up and down.

[Dirk Schulze]

(In reply to comment #0)
> On compositing tiles, filters are clipped and refiltered. This has really strange effects on gaussian blur filters. See the example at http://codepen.io/adobe/pen/eJHgl move the slider for the bottom iframe up and down.

A static tile grid doesn't work great for many SVG filters. There will always be situations where feDisplacementMap, feDropShadow, lightning filters, feGaussianBlur need pixels from different tiles. For feDisplacementMap it can even be hard to impossible to predict the exact area of possibly requested pixels.

[Dirk Schulze]

It seems to be correct for CSS filter functions.

I'd like to understand what is going on. It seems that we filter the whole element area for every tile. So for blur(10px) we would blur the element twice if the element is part of two tiles. Is that correct? Or are there other optimizations that just let us copy the margin area of the element that is required by the blur() filter? Even with the optimization (if it is implemented at all), SVG Filters like feDisplacementMap would suffer from the same problem and we would need to filter the whole element area.

[Radar WebKit Bug Importer]

<rdar://problem/18216351>

[Lutz]

Created attachment 238715 [details]
when a html-element is larger as the screen, than the drawing of th html-element is getting irritated by the standard-copositing-border-matrix

when a html-element is larger (height or width) as the screen, than the drawing of th html-element (with an svg-filter applied) is getting irritated by the standard-copositing-border-matrix.
The workarounds (to get separate Layer with) did not helps when element is bigger than screen, because compositing gets than again the standard-matrix(tile-size).
Example-Workarounds which did not help in this case:
-webkit-transform: matrix3d(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1) translate3d(0, 0, 0);
-webkit-transform: scale(1);
-webkit-transform: translateZ(0);
-webkit-backface-visibility: hidden;

[Lutz]

Created attachment 238716 [details]
html-element with svg-filter gets irritated by compositing-borders

[Lutz]

Created attachment 238717 [details]
when a html-element is larger as the screen, than the drawing of th html-element is getting irritated by the standard-copositing-border-matrix

when a html-element is larger as the screen, than the drawing of th html-element is getting irritated by the standard-copositing-border-matrix

when a html-element is larger (height or width) as the screen, than the drawing of th html-element (with an svg-filter applied) is getting irritated by the standard-copositing-border-matrix.
The workarounds (to get separate Layer with) did not helps when element is bigger than screen, because compositing gets than again the standard-matrix(tile-size).
Example-Workarounds which did not help in this case:
-webkit-transform: matrix3d(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1) translate3d(0, 0, 0);
-webkit-transform: scale(1);
-webkit-transform: translateZ(0);
-webkit-backface-visibility: hidden;

[Simon Fraser (smfr)]

I don't see any issues with the examples in this bug now.