Re: [fxtf-drafts] [filter-effects] Clarify "smoothing technique" for feSpotLight's limitingConeAngle

When I rewrote our software filter implementation in 2013, I chose to respect the kernelUnitLength in a different way, instead of using scaling: In Firefox, the convolution now operates in device pixel space. When sampling from the input image, the sample points are spaced further apart, depending on the kernel unit length. If the kernel unit length is a fractional device pixel amount and the sample points fall between device pixels on the input image, bilinear interpolation is used to compute the sampled color value.
This approach can lead to a sharper result, but it's slower and can look worse in other ways. (And especially with lighting filters, you usually don't mind a bit of blurriness...)
I'd probably make a different decision today if I had to implement filters again, and go for the downscale approach.

The description above only applies to the software filter backend. The Direct2D backend simply passes along the kernel unit length to the D2D effect, and I don't know how that interprets it. The result is probably very close to what Edge does.

I should also note that, if no kernelUnitLength is specified, Firefox still defaults to one device pixel and not to one CSS pixel or user space unit.

GitHub Notification of comment by mstange
Please view or discuss this issue at using your GitHub account

Received on Friday, 5 January 2018 10:01:26 UTC