Re: [filter-effects] resolution dependent filter primitives

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.

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.