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

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



On Tue, Feb 26, 2013 at 6:17 PM, Gregg Tavares <gman@google.com> wrote:
>
>
>
> On Tue, Feb 26, 2013 at 4:47 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
>>
>> 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.
>
>
> Why do you think GL stops "gl_" on bindAttribLocation? By your logic (which
> I agree with) it could just drop those on the floor as well right? I've
> assumed there was a reason.
>
> If I had to guess I'd guess so they can later add some special
> "gl_specialAttribThingy" and let you call glBindAttribLocation(prg, index,
> "gl_specialAttribThingy") to bind it to a specific attribute. If they didn't
> preemptively reject it in bindAttribLocation then there's the possibility
> someone is passing that in already which would be silently ignored and then
> someday suddenly not silently ignored?? So, I've assumed we should do the
> same for our reserved prefixes.

I agree. This has been the tested behavior for WebGL implementations
for some time and I see no reason to relax or change it.


> As for _webgl_ I'm pretty sure that comes from the discussion group. No idea
> why
>
> http://www.khronos.org/webgl/public-mailing-list/archives/1003/msg00095.html

I think Cedric's idea at the time was that an extension might expose a
variable "webgl_foo" to shaders that developers were supposed to be
able to access. (At the time, we were talking about exposing a
synthetic "webgl_InstanceID" variable.) Identifiers starting with
"_webgl_" would be used only by implementations. Again, I do not think
the reservation of these namespaces should be changed.

-Ken


>
>
>
>
>
>
>>
>>
>> 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
-----------------------------------------------------------