Re: [filters] Shading language recommendation

On Tue, Aug 21, 2012 at 2:32 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> Hi,
>
> On Aug 21, 2012, at 2:03 PM, Dean Jackson <dino@apple.com> wrote:
>
>>
>> On 22/08/2012, at 2:52 AM, Sylvain Galineau <sylvaing@microsoft.com> wrote:
>>
>>> The normative prose of section 38.2 'Recommended shading language' recommends
>>> GL SL ES [1]. Per RFC2119 this means implementers MUST support GL SL ES
>>> unless there exist 'valid reasons in particular circumstances' to ignore this
>>> recommendation.
>>>
>>> While Microsoft has no objection to defining how the feature works for UAs
>>> that choose GL SL ES as defined by Web GL 1.0, we object to its normative
>>> recommendation.
>>
>> Can you explain why you object? You mention below what you'd prefer, but don't
>> provide reasoning.
>>
>> The informative section related to media codecs is there because there are
>> well-known IP issues around that technology. As far as I am aware, this does
>> not apply in the case of shading languages.
>>
>> Also, don't you (Microsoft) agree there is a significant penalty if we don't require
>> a single shading language? What is it in particular about GLSL that you object
>> to?
> CSS Shaders as well as Filter Effects never required GLSL (on base of WebGL), but it is the recommended shading language. Therefore I don't share Sylvain's concerns that an implementation must support GLSL.
>
>>
>> Dean
>>
>>> This was the reason for the note in the same section, note
>>> which looks at best confusing if not contradictory given the normative
>>> recommendation that precedes it.
>>>
>>> We would prefer to follow a pattern similar to the informative section 6.1 in
>>> Media Source Extension[2]: "This section defines segment formats for
>>> implementations that choose to support WebM". We think the ability to specify
>>> multiple shading languages is important, as broadly suggested by the current
>>> note. This allows sites to work with different user agents supporting different
>>> shading languages. For example, a future version of GL SL ES with fallback to
>>> the current version for user agents that don't yet support the new version.
> I think it is a good idea to think about future versions of GLSL as well. Therefore adding a feature string that helps the UA to decide if a shader is supported or not, and provide a fullback shader doesn't sound like a bad idea.

GLSL ES versions are self-describing. That is, all future versions of
GLSL ES should contain a declaration like:

#version 300 es

which directs consumers as to the semiotics required for handling.

The family of GLSL ES languages (including versions, shader stages,
and per-vendor deviations) should be registered as a single IANA media
type like every other legitimate web language. This problem of
different resource representations has been encountered again and
again on the net (and the Web). Media types are the solution that the
platform has adopted.

Publication of an RFC and registration of a media type helps keep
WebGL and its shading language as the standard. MS can and will
compete with whatever software it wishes. A single URI can identify a
collection of equivalent resources through HTTP content negotiation
and no new API is required.

It is time for GLSL ES to come into the Open Web and compete in the
marketplace of ideas. Khronos should register "application/webglsl"
with an optional version parameter, open the GLSL ES WG completely to
the public, and invite MS to attempt to compete.

Stewardship and inclusion beats hegemony and exclusion in the Age of Knowledge.

David

> Greetings,
> Dirk
>
>>>
>>>
>>> [1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#recommendation
>>> [2] http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
>>>
>>>
>>>
>>
>>
>
>

Received on Tuesday, 21 August 2012 23:55:48 UTC