Re: [filter-effects] resolution dependent filter primitives

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

filterRes was deprecated and removed from the spec. It is just kernelUnitLength that is left.

I am not convinced if it is worth it to keep kernelUnitLength. You never know how kernelUnitLength is relative to device units OR to your object, see previous discussions. So you are better on with having high DPI results but platform dependent or you want to have it exactly depending on your userSpaceInUse coordinates which probably will reduce quality. Of course, if you put it in userSpaceOnUse, there are cases where you could ridiculously increase the pixel density and the browser may need to reduce it again or runs out of memory. Example:

<g transform=“scale(0.0001)”>
<g filter=“url(#filter)”>
<rect transform=“scale(100)” width=“1000” height=“1000"/>
</g>
</g>

The resulting rect size would be 100x100, yet the filtered object would be 100000x100000.

So even if we add a flag to switch between device pixels and userSpaceOnUse, it would still just be a hint for the UA.

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.

That said, even with a new attribute there are situations where even the UA has problems to calculate the correct device dependent resolution for offscreen buffers (actually affecting all primitives and not just feConvolve and lighting). For example if your filtered object is rendered in a 3D context and rotated in the 3D space for instance.

Greetings,
Dirk