W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2011

Re: [css-shaders] GLSL implementation defined limits

From: Chris Marrin <cmarrin@apple.com>
Date: Thu, 17 Nov 2011 11:00:47 -0800
Cc: Gregg Tavares <gman@google.com>, "public-fx@w3.org" <public-fx@w3.org>
Message-id: <FA1FCAE3-3B28-4B88-AF4B-65AF11689537@apple.com>
To: Vincent Hardy <vhardy@adobe.com>

On Nov 16, 2011, at 8:55 PM, Vincent Hardy wrote:

>> ...Should we mention anything about how failures might be handled? In reading the @supports documentation (http://dev.w3.org/csswg/css3-conditional/), that might be a fine approach. If you say:
>> 
>> @supports ( filter: shader(url(shader.vs) url(shader.fs) ...) ) {
>> 	.myfilter { filter: shader(url(shader.vs) url(shader.fs) ...); }
>> }
>> 
>> @supports not ( filter: shader(url(shader.vs) url(shader.fs) ...) ) {
>> 	.myfilter { filter: shader(url(fallback.vs) url(fallback.fs) ...); }
>> }
>> 
>> then you can compile and link the shader in the @supports statement, and know at that point whether or not it can be used. This is pretty wordy, requiring the shader to be stated 3 times. It would be nice if @supports had the ability to have an else clause, like:
>> 
>> @supports ( filter: shader(url(shader.vs) url(shader.fs) ...) ) {
>> 	.myfilter { filter: shader(url(shader.vs) url(shader.fs) ...); }
>> }
>> @else {
>> 	.myfilter { filter: shader(url(fallback.vs) url(fallback.fs) ...); }
>> }
>> 
>> to cut out one of those. But maybe that's overkill. either way, you'd need to encapsulate the shader program and make it possible to compare programs to avoid needless reconstruction of the shader.
> 
> >> Reading section 6.1 of CSS conditionals (http://dev.w3.org/csswg/css3-conditional/#support-definition), it seems to me that the @support rule is about testing if a particular property/value pair is supported in general. I think what you are suggesting goes a bit beyond, in that the implementation needs to both support the filter effect and the shader() function _and_ successfully load/compile/link the referenced shader. I think that would be a new feature. In some way, it seems to me that what you are asking for is more like multiple <video> sources, where the author can specify several sources. If one fails to load or is not supported (because of the source's type), then the next one can be used.
> 
> >> I also think that the case of basically invalid shader code or shader that fails to load is similar to a JavaScript that fails to load or is invalid. This may break the page. I am not quite convinced that the situation with shaders is unique compared to scripts and warrants a new mechanism.

The inability to load shaders is pretty unique. There are no instances I know of where JavaScript will fail based on hardware constraints. I agree that this stretches the meaning of @supports, but I think it is asking a reasonable question, to wit: "if I try to use this expression, will it work?". But I also think it would be reasonable to use a different conditional, something like, @will-it-blend. :-) 

-----
~Chris
cmarrin@apple.com
Received on Thursday, 17 November 2011 19:02:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 17 November 2011 19:02:16 GMT