W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > January 2018

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

From: Markus Stange via GitHub <sysbot+gh@w3.org>
Date: Fri, 05 Jan 2018 10:01:16 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-355516782-1515146474-sysbot+gh@w3.org>
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 https://github.com/w3c/fxtf-drafts/issues/244#issuecomment-355516782 using your GitHub account
Received on Friday, 5 January 2018 10:01:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:21 UTC