Re: Filter Effects and High DPI

On Wed, Mar 20, 2013 at 12:22 PM, Gregg Tavares <gman@google.com> wrote:

>
>
>
> On Mon, Mar 18, 2013 at 3:24 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>>
>>
>> On Fri, Mar 15, 2013 at 2:40 PM, Gregg Tavares <gman@google.com> wrote:
>>
>>>
>>>
>>>
>>> On Fri, Mar 15, 2013 at 2:33 PM, Dirk Schulze <dschulze@adobe.com>wrote:
>>>
>>>>
>>>> On Mar 15, 2013, at 1:50 PM, Gregg Tavares <gman@google.com> wrote:
>>>>
>>>> > This brings up an issue that I don't *think* is addressed by the
>>>> current custom filters proposal?
>>>> >
>>>> > In custom filters, assuming they use GLSL, there are global values
>>>> available. For example
>>>> >
>>>> >      gl_FragCoord
>>>> >
>>>> > that are in device coordinates. If we want CSS custom filters to be
>>>> device independent the spec will probably need to mention that shaders
>>>> using gl_FragCoord are disallowed or else that implementations must
>>>> re-write the shader so that gl_FragCoord is in CSS pixels and not device
>>>> pixels.
>>>> >
>>>>
>>>> gl_FragCoord must be in device coordinates to provide access to the
>>>> texture data. For shaders it doesn't makes sense that the pixel information
>>>> ar win CSS coordinates. Ditto for the textureSize uniform which represents
>>>> the actual texture size. I added a description to the spec to clarify this
>>>> fact.
>>>>
>>>
>>> The problem you'll have is the texture size will be different on an
>>> HD-DPI display vs a LO-DPI display and effects like generating a
>>> checkerboard from gl_FragCoord will generate the wrong size checkerboard.
>>>
>>
>> That is assuming that you don't want the checkerboard to always be in
>> device pixels (ie the 'transparency' checkerboard pattern in Photoshop does
>> not scale so this is something that you could use a custom device-dependent
>> shader for)
>> If an author wants device independent custom filters, he should write
>> them using relative coordinates.
>> If the author desires a device dependent rendering, he can use
>> "gl_FragCoord". "u_devicePixelRatio" could then be used to scale the
>> output of the shader so it looks the same on low and high DPI devices,
>>
>
> I'm assuming that introducing device dependencies into CSS is a bad idea.
> Devs will write some custom filter, expect it works everywhere, then have
> to test on every different device on every browser to see if it worked.
> That's not true in any other Web API I know of.
>

Yeah, it's a bit strange.
There is precedent though since both feConvolveMatrix and feDiffuseLighting
can produce device dependent output. The new 'HD' methods of canvas can
also be seen as device dependent.

The spec for custom filters should be updated so have the same language as
the 2 svg filters.
Shouldn't it also specify what happens when you zoom?