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

Re: [Public WebGL] texture/renderbuffer deletion behavior when they are bound to non-bound framebuffer

On Thu, Sep 9, 2010 at 4:45 PM, Mo, Zhenyao <zhenyao@gmail.com> wrote:
> According to GLES2 spec, if a texture/renderbuffer object is bound to
> the currently-bound framebuffer and it's deleted, it is first
> detached.  However, if the framebuffer is not currently bound, then it
> "is specifically NOT detached ... Detaching ... is the responsibility
> of the application."
> This sounds to me like a security issue where crash could happen.  I
> suggest to make it stronger for WebGL spec that no matter the
> framebuffer is bound or not, when one of its attachment is deleted, we
> always detach first.
> Please advise.

This does sound like an unclear area in the OpenGL spec. For example,
what happens if you query GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME for
the color attachment of such a framebuffer? The texture is still
referenced by the framebuffer, so it probably hasn't been actually
deleted, but the name is no longer accessible in the context's

However, I'm not sure that this is really a security issue. OpenGL
implementations are expected to not crash in this situation. If one
does, then a given WebGL implementation might need to work around the
crash, but I'm not convinced that an explicit mention of this in the
spec, and associated divergence from OpenGL ES 2.0 behavior, is


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: