Re: [css-shaders] GLSL implementation defined limits

On Fri, Nov 11, 2011 at 10:17 AM, Chris Marrin <cmarrin@apple.com> wrote:

>
> On Nov 10, 2011, at 6:35 PM, Vincent Hardy wrote:
>
> > Hi Gregg,
> >
> > On Nov 10, 2011, at 4:20 PM, Gregg Tavares (wrk) wrote:
> >
> >> Up until this point, AFAIK, CSS you either have a feature (like 3D css)
> or you don't but if you do have the feature then for the most part there
> aren't too many situations where you'll run into serious limits.
> >>
> >> In other words, while you have to worry that whether or not gradients
> exist, if they do exist you can generally count on them working for all
> reasonable inputs.
> >>
> >> But that's not true with CSS shaders.  It will be very easy to create
> CSS shaders that work on some hardware but not on others either by making
> them too long or by exceeding other limits of the user's GPU.
> >>
> >> WebGL leaves this up to the dev to deal with but it's a programatic
> API. You can check that it failed at runtime.
> >>
> >> CSS is generally declare and forget.
> >>
> >> Should it be that if any CSS shader on a page does not compile that all
> CSS shaders on the page should be ignored? That would at least mean that
> you don't have some elements displaced and others not. You either get
> everything you intended or you get your fallback, no CSSshader layout.
> >>
> >> Of course that's problematic since CSS shaders can be changed and/or
> applied on the fly
> >>
> >> Maybe specifying some maximum limits or min spec hardware or
> something...?
> >>
> >
> > I think you bring up several issues.
> >
> > - Incorrect shaders. I think this should be handled like incorrect CSS.
> If the shader does not compile, it behaves as if no shader is specified.
> WIth the WebGL restrictions on shaders, there is a base interoperability so
> I think the definition is tight enough that shaders would be compatible on
> all implementations. The proposal actually has some wording about incorrect
> shaders, see
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html#feCustom.
> >
> > - Hw limitations. There may be wide enough variations between hw that
> makes a shaders perform ok on one platform and not fast enough on another.
> I think this is tricky, and if the content author wanted to do something
> different based on that knowledge, we would need to have a kind of 'hw
> capabilties' media query. I understand the concern and need, I am not clear
> on how we would go about classifying hardware capabilities. Do you have a
> suggestion?
>
> I don't think there is any way to announce hardware capabilities. Even if
> we gave the author the ability to discover details such as number of
> texture units, uniforms, and GPU program memory, there will be hardware
> that seems to have all the needed capabilities but that still can't run the
> shader because of some combination of the features being used. I think the
> best we can do is to have a minimum set of functionality that authors can
> try to stay within to have the best chance of interoperability. Then we
> should figure out some way of having fallback style for when a shader does
> fail.
>
> 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?
>

That doesn't seem like enough. If one shader works and other doesn't it's
unlikely the page as a whole is going to work.

1) I could have effects the depend on each other. On other words, I need 2
or more elements to be transformed. if only 1 is transformed the visuals on
the page don't work.

2) I could have Javascript processing mouse events. How do I know if a
shader failed so that I can then use the appropriate math in my JavaScript?




>
> -----
> ~Chris
> cmarrin@apple.com
>
>
>
>
>