[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] bindAttribLocation on _?webgl_ attribs



We do inherit GL's behavior, but there's no reason to expand WebGL's behavior here without reason, nor should we just s/gl/webgl/ everything. Since restricting it here goes further than what GL mandates, and it doesn't win us anything, it seems unnecessary to restrict this.

Further, s/gl/webgl/ here would only add the reserved "webgl_" prefix. I'm not sure why we reserve "_webgl_".

-Jeff


----- Original Message -----
From: "Kenneth Russell" <kbr@google.com>
To: "Jeff Gilbert" <jgilbert@mozilla.com>
Cc: "public webgl" <public_webgl@khronos.org>, "Gregg Tavares" <gman@google.com>
Sent: Tuesday, February 26, 2013 3:29:30 PM
Subject: Re: [Public WebGL] bindAttribLocation on _?webgl_ attribs

The manual page for glBindAttribLocation states:

  GL_INVALID_OPERATION is generated if name starts with the reserved
prefix "gl_".

WebGL's corresponding entry point should behave the same for WebGL's
reserved prefixes, not silently drop the call on the floor.

-Ken



On Tue, Feb 26, 2013 at 3:17 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
> I don't see why it's needed, though. The WebGL impl can easily just drop these bindings on the floor, since there's no possible time when they'd be valid. (All shaders containing them should fail to link, presumedly)
>
> I don't see a good reason for keeping this restriction in light of how easy it should be to just ignore such calls. Failing that, we should clarify the language, yes.
>
> -Jeff
>
> ----- Original Message -----
> From: "Kenneth Russell" <kbr@google.com>
> To: "Gregg Tavares" <gman@google.com>
> Cc: "Jeff Gilbert" <jgilbert@mozilla.com>, "public webgl" <public_webgl@khronos.org>
> Sent: Tuesday, February 26, 2013 2:39:35 PM
> Subject: Re: [Public WebGL] bindAttribLocation on _?webgl_ attribs
>
> Yes, that's correct.
>
> It wouldn't be acceptable if the application developer could call
> bindAttribLocation passing in an identifier starting with one of the
> reserved prefixes and have that apply to an attribute allocated
> internally by the WebGL implementation.
>
> Should this sentence be clarified and perhaps separated out into a
> separate subsection which can be referred to independently of
> "Supported GLSL Constructs"?
>
> -Ken
>
>
>
> On Tue, Feb 26, 2013 at 2:01 PM, Gregg Tavares <gman@google.com> wrote:
>> If the WebGL spec is not clear it should be updated. It's trying to match
>> the OpenGL ES spec but add a prefix. Everywhere "gl_" is disallowed WebGL
>> also wants to disallow "webgl_"
>>
>>
>>
>>
>>
>> On Tue, Feb 26, 2013 at 1:11 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
>>>
>>>
>>> The test suite has this:
>>> gl.bindAttribLocation(program, 0, 'webgl_a') expected: INVALID_OPERATION
>>> gl.bindAttribLocation(program, 0, '_webgl_a') expected: INVALID_OPERATION
>>>
>>> I don't see where this is in the spec. The GLES2 spec has this behavior
>>> for attribs starting with 'gl_', but I can't find the language in the WebGL
>>> spec which amends this. It seems like this shouldn't be strictly necessary
>>> anyways, since we already have this language in the spec:
>>>
>>> "In addition to the reserved identifiers in the aforementioned
>>> specification, identifiers starting with "webgl_" and "_webgl_" are reserved
>>> for use by WebGL. A shader which declares a function, variable, structure
>>> name, or structure field starting with these prefixes must not be allowed to
>>> load."
>>>
>>> With this restriction, it seems that the user couldn't declare an attrib
>>> with such a name anyways, so bindAttribLocation with these prefixes would
>>> always do nothing to a shader which meets this restriction, while refusing
>>> to 'load' (link? use? This should probably be clarified as well.) shaders
>>> which conflict with this passage.
>>>
>>> It seems like we don't need this restriction, so it should be removed. Is
>>> there something I'm missing?
>>>
>>> -Jeff
>>>
>>> -----------------------------------------------------------
>>> You are currently subscribed to public_webgl@khronos.org.
>>> To unsubscribe, send an email to majordomo@khronos.org with
>>> the following command in the body of your email:
>>> unsubscribe public_webgl
>>> -----------------------------------------------------------
>>>
>>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------