[Public WebGL] Specifying the behavior of bindXXX when passed a deleted resource
Tue Jun 18 15:58:40 PDT 2013
I vote for following closely to the GL behaviors, i.e.,
1) bind a texture/render_buffer/buffer that's deleted will generate an
error, the object becomes invalid as soon as delete* is called.
2) useProgram / attachShader and other queries are still valid when
deleteProgram / deleteShader is called but they haven't been truly
On Tue, Jun 18, 2013 at 3:45 PM, Gregg Tavares <[email protected]> wrote:
> So the GL group says you can continue to use call useProgram on a program
> marked for deletion but that has not actually been deleted yet. Once it has
> actually been deleted you'll get an error
> Should we do the same for all resources in WebGL?
> On Tue, Jun 18, 2013 at 12:14 PM, Gregg Tavares <[email protected]> wrote:
>> Actually I'm not sure what should happen here and AFAICT it's not clear
>> from the ES spec.
>> The ES spec doesn't say what happens if you call useProgram on a program
>> marked for deletion but not actually deleted but it is clear you can still
>> use the object for things like GetProgramiv as that's how you query if it's
>> marked for deletion.
>> If they decided to make other resources behave like shaders and programs
>> (ie, you must call glGenXXX to create an id and glBindXXX stops creating
>> resources and delete behaves the same), then there's all kinds of
>> interesting questions
>> If you can useProgram a program marked for deletion but not deleted then
>> you should be able to bindTexture a texture marked for deletion but not
>> Similarly you should be able to call getTexParameter on a texture marked
>> for deletion just like you can call getProgramParameter on a program marked
>> for deletion
>> Other queries and binds would also seem to work.
>> I don't think that would be a problem. In that case bindXXX and useProgram
>> would only fail on objects actually deleted, not objects just marked for
>> deletion. I know Chrome would have no problem with that as we already don't
>> actually call glDeleteXXX on anything unless all its references are gone
>> since there are driver bugs otherwise. I'm pretty sure Firefox does the
>> I've asked for some input from the OpenGL WG.
>> On Mon, Jun 17, 2013 at 10:16 AM, Zhenyao Mo <[email protected]> wrote:
>>> 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.
>>> 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 identiﬁes 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:
More information about the public_webgl