[Public WebGL] Specifying the behavior of bindXXX when passed a deleted resource

Zhenyao Mo [email protected]
Mon Jun 17 10:16:23 PDT 2013


Yes and yes.

But for gl.userProgram, we need to be more careful to define the
"deleted" state, because the name is still valid after
gl.deleteProgram if it's currently bound.

Mo

On Fri, Jun 14, 2013 at 3:33 PM, Gregg Tavares <[email protected]> wrote:
> AFAICT the WebGL spec is currently silent on what happens when you bind a
> deleted resource.
>
> In other words
>
>     var tex = gl.createTexture();
>     gl.deleteTexture(tex);
>     gl.bindTexture(gl.TEXTURE_2D, tex);  // What does this do?
>
> The conformance tests expect that to bind 0 [glBindTexture(gl.TEXTURE_2D,
> 0)] but the WebGL spec doesn't say that's what's supposed to happen.
>
> We need to update the spec but I'm also curious if we should change the
> behavior. Should that bind above generate INVALID_VALUE or should it stay as
> is and bind 0?
>
> The same is true of gl.useProgram. Calling useProgram on a deleted program
> ends up calling glUseProgram(0) but that's not in the spec. In fact it's
> specifically against the spec as the ES 2.0.25 spec, 2.10.1 says
>
> Commands that accept shader or program object names will generate the error
> INVALID_VALUE if the provided name is not the name of either a shader or
> program object and INVALID_OPERATION  if the provided name identifies an
> object that is not the expected type.
>
>
> We either need to fix implementations and tests to match the ES spec or
> update the WebGL spec to document the different behavior.
>
> Should binding a deleted resource generate an error? My vote = yes.
> Should useProgram follow the ES spec and generate an error? My vote = yes
>
> Thoughts?
>
>

-----------------------------------------------------------
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------





More information about the public_webgl mailing list