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

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



Hi Gregg,

On Jun 18, 2013, at 3:45 PM, Gregg Tavares <gman@google.com> 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?

IMO if it is specified somewhere when the real deletion happens (flush ?) then behaving like GL might be better performance wise.
Otherwise without a clear deterministic place to know when the resources are deleted for sure, I would say it would be more explicit that the resource is deleted right away. (at least appears so in WebGL).

Fabrice.




On Tue, Jun 18, 2013 at 12:14 PM, Gregg Tavares <gman@google.com> 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 deleted.
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 same.

I've asked for some input from the OpenGL WG.



On Mon, Jun 17, 2013 at 10:16 AM, Zhenyao Mo <zmo@chromium.org> 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.

Mo

On Fri, Jun 14, 2013 at 3:33 PM, Gregg Tavares <gman@google.com> 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?
>
>