RE: [filters] Shading language recommendation

[Dirk Schulze:]

> > 1) We believe the conformance of a Filter Effects implementation should
> not depend on its use of GL SL ES i.e. if a UA wants to support this
> functionality with a different technology they should be able to do so.
> Yes, I agree. And it is possible like shown with ANGLE.

I'm not sure how you can both agree that implementations should not have 
to depend on GL SL and suggest a technology that requires GL SL input 
as an alternative?

> 
> > 2) Generally speaking, we do not believe a CSS feature should require,
> recommend or depend on a specific low-level technology such as a shading
> language. We are not aware of any such dependencies to date and believe
> such architectural concerns should be kept orthogonal. As CSS
> specifications generally avoid even taking a dependency on a specific
> document language it is very unusual for a module to recommend a
> technology which, from a CSS standpoint, has been an implementation detail
> to date. A clear compelling reason to do so should at least be explicitly
> articulated in the specification.
> GLSL is a shading langage. But it does not mean that it is a low-level
> technology or relies on low level technologies. ANGLE is one project that
> aims to parse and translate GLSL.

This sounds a bit semantic. GL SL is very much a low-level language for a 
population of developers who are largely not comfortable using even the 
matrix() transform function. I would expect the number of people who write 
custom shaders to be far smaller than the number of people who use them. 
But I do not think this is very relevant to our feedback.
 
We understand that ANGLE parses and translates GL SL; but the question is 
not whether GL SL can be translated to something else or how. The issue 
is recommending/requiring GL SL to define custom filters or shaders. 

Can we at least agree that if requiring/recommending language X is a 
concern then technologies that require X as input will not resolve 
said concern?

> 
> > 3) More specifically, if the feature aims to provide an entry point to
> lower level capabilities for extensibility purposes e.g. custom CSS
> shaders, we believe there should be a mechanism to support alternative
> languages; this would also future-proof the platform.
> The specification has a section that mentions various possible (and
> considered) shading languages. We choose GLSL over others, since WebGL is
> widely implemented and exposed to browsers. A lot of developers are
> already familiar with GLSL. There is nothing similar available for the web
> at the moment. In general I am not opposed to more shading languages, but
> a default, required language seems to be in the interest of web
> developers.

You indicated earlier that 'CSS Shaders as well as Filter Effects never 
required GLSL'; you now indicate this is in fact meant to be the 'default, 
required language'. Can I assume the latter is your preferred outcome from 
now on?

We believe choice is also in the interest of developers at this time. If 
those developers interested in writing custom shaders  already prefer a 
specific language we have no objection to their being able to use it. Once
again, we object to any specific language being required/recommended at this 
point. We do not object to the spec allowing the use of GL SL or informatively
documenting how GL SL can be used for the purpose of authoring custom shaders.
 
> 
> > 4) We are concerned that including GL SL as a RECOMMENDED feature makes
> it an essential feature under the W3C Patent Policy. We don't believe the
> shading language itself is within the scope of the CSS WG charter and we
> didn't carry out the  comprehensive IP review that would be necessary for
> us to participate on that basis. We suspect that other organizations also
> didn't do this.
> We were about to publish a FPWD. Every member of the W3C has three weeks
> to verify if own patents are affected and if it wants to object if they
> are.

I do not yet know whether three weeks is enough for such a review but I will ask.

> 
> > I would like to resolve this before FPWD.
> 
> The SVG WG and the CSS WG agreed to publish a FPWD of Filter Effects. If
> you object to the decisions of the WGs now, it is necessary to request a
> resolution from the WGs to not publish FPWD.

I am quite aware of that and I apologize for the late timing of this feedback.
If there are minutes showing discussion of this specific section in its current
form and agreement that it is in scope, do let me know. 

At this time I would prefer to find a way to publish a FPWD that clearly reflects 
the issue for all who use it.

Received on Wednesday, 22 August 2012 23:01:14 UTC