Re: [filter-effects] resolution dependent filter primitives

On Nov 6, 2013, at 11:08 AM, Jasper van de Gronde <th.v.d.gronde@hccnet.nl<mailto:th.v.d.gronde@hccnet.nl>> wrote:

On 2013-11-05 12:41, Dirk Schulze wrote:

On Nov 5, 2013, at 9:12 AM, Michael Mullany <michael@sencha.com<mailto:michael@sencha.com>> wrote:


...
Given that it's already implemented in both Firefox and IE10+, I'd vote for retaining kernelUnitLength as the way to poke the UA to do the "right thing" however the developer/author chooses to define that, rather than introducing a new attribute.

The problem is that you may not know the “right thing” as author either. You don’t know the pixel density and current transformation when you specify kernelUnitLength. Then you may have kernelUnitLength relative to the objectBoundingBox or userSpaceOnUse (say 1) but you don’t know what they actually mean in many cases. This will either look absolutely ugly and pixelated when it is rendered… Or you chose a resolution that is too big for the device resolution of your device and the UA will try to scale it down or refuse rendering. As you say earlier, you couldn’t get it working in Firefox in a way it didn’t look pixelated.
Although the spec (currently) specifies that these filters all work on a specific grid, there is really no reason to assume an implementation couldn't just apply the filter on a different grid using an appropriate resampling / approximation algorithm. This should definitely not look pixelated. At worst this would look a little blurry, but not for a high dpi screen, you'd just get an incredibly smooth result. Also when scaling the image, you'd basically get what you want.

I don’t think that the specification still implies a fixed grid. But there are more documented issues to make clear that most filters are described platform independent and that UAs need to scale parameters to have consistent results across platforms.

We are not discussing these primitives that are easy to scale like gaussian blur and most of the other primitives. We are more discussing the two filter primitive groups that can not be scaled in a straight forward way: feConvolveMatrix and feLighting. SVG 1.1 introduced kernelUnitLength to have consistent results across implementations. Doing that introduces a device independent image buffer size that you describe as “grid”. I am just saying that it is hard to align this grid to the actually desired result. Even if you do (by element specific filters), the result will indeed look “blurry” or pixelated. This is noticeable especially on high DPI displays.


If you want ultimate total control over the result, it might just be better to introduce something like primitiveUnits=native or something. Or some other option that essentially guarantees "crisp" results. Conceptually, however, it would be /so/ much easier to be able to essentially forget about resolution and just think about scale.

Right, that is why we removed filterRes. Again, it works for most filter primitives. It doesn’t work for the two categories described above.

Greetings,
Dirk