[filter-effects] Specify rounding behaviour of feMorphology radius attribute

[BigBadaboom]

https://www.w3.org/TR/filter-effects/#element-attrdef-femorphology-radius

The radius attribute determines the size (row and column count) of a convolution kernel. Obviously this eventually has to be rounded to an integer to create the matrix. However the spec does not say what the rounding method is.

Testing this, it appears that FF always rounds up, and Webkit always rounds down. So, for example 0.4 becomes 0 on Chrome (disabling the filter) and 1 on Firefox (filter works).

I believe it would be a good idea to add a note to this section formalising the rounding method. If you are familiar with convolutions, it is obvious that only integers should be used, but that is not obvious to the average person.

[BigBadaboom]

@RLongson has pointed out to me that FF actually rounds down if the fraction is below an epsilon of 0.0001. So 0.0001 becomes 0, but 0.0002 is rounded up to 1. Thanks Robert.

[bungeman]

Blink is looking to change its behavior in M84 (see https://chromium-review.googlesource.com/c/chromium/src/+/2132426 ). Previous to this change the radii were calculated in css pixels, then floored to integer css pixels, then sent through the CTM to get to physical pixels and then floored again to integer physical pixels to do the actual effect. To avoid the double flooring this is being changed to remove the intermediate floor in css pixels and round instead of floor in physical pixels. So the new behavior is map the radii through to physical pixels and then round the radii just before applying the effect to the physical pixels.

After a quick look at the Firefox implementation it wan't immediately clear at what stage the conversion to integer was happening (in css or physical pixels). In general it seems best to put off any conversion to integer until actually doing the effect to physical pixels.

The consensus locally seems to be that the old behavior of flooring probably isn't a good idea. Effectively taking the ceiling as Firefox does seems to have some merit as it always provides some effect if a radius is non-zero. We ended up picking rounding (before finding this issue) since it picks the closest integer. Another possibility is for anything greater than zero but less than one to go up to one but for other values to round.