Re: [css-shaders] GLSL implementation defined limits

On Fri, Nov 11, 2011 at 2:50 PM, Chris Marrin <cmarrin@apple.com> wrote:
> On Nov 11, 2011, at 12:29 PM, Tab Atkins Jr. wrote:
>> On Fri, Nov 11, 2011 at 10:17 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>> I'm not actually sure of how CSS handles fallback. Maybe we could do this:
>>>
>>>        .filtered: {
>>>                filter: shader(<my complicated shader>);
>>>                filter: shader(<my less complicated shader>);
>>>                filter: blur(3);
>>>        }
>>>
>>> So if the complicated shader fails, it will try the less complicated one. If that fails, it will use a simple blur. Would that work?
>>
>> No, that sort of fallback is parser-level, to allow you to provide
>> fallback for *syntax* that legacy UAs don't understand.  UAs are
>> allowed to (and do) throw away all the rules that are "replaced" by
>> later ones.  In your above example, the .filtered class would just
>> receive a blur(3).
>>
>> We do have some feature-level fallbacks, but they have to be defined
>> explicitly.  The 'font-family' property takes a list of fonts and uses
>> the first one it can find that has the correct glyph.  The 'image()'
>> function defined in CSS3 Image Values takes a list of images and
>> represents the first one that the browser understands.  One could
>> design something similar for shaders, but I'd want a clear explanation
>> of the use-cases, but I don't think copying the 'image()' solution
>> would help Gregg.
>
> Well, maybe it would though. You could do something like:
>
>        .filtered {
>                filter: shader(program url(complex.vs) url(complex.fs), program url(simple.vs) url(simple.fs), ...);
>        }
>
> The new 'program' parameter groups a vs and fs. The first set that succeeds is used. Isn't that similar to what image() does? This doesn't allow a fallback to something that is not a shader, but I think that's probably ok. You just need to supply a shader that you're confident will run on all platforms. In fact, this would give authors a pretty powerful tool. They could go pretty nuts with exotic shaders, and as long as they also provide something more tame, everyone will see something reasonable.

This doesn't address Gregg's use-cases, where multiple filters may be
working together and be useless or harmful if only one isn't runnable,
or where script may be running in conjunction with the filter that
assumes the filter is working.

~TJ

Received on Friday, 11 November 2011 22:55:16 UTC