[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 6:31 PM, Kenneth Russell <kbr@google.com> wrote:
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
namespace.

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

Looks like your right Ken.  The relevant discussion seems to be in EXT_framebuffer_object issues 77 and 34.  The storage for the renderbuffer/texture is not released until all references are gone, rendering continues as normal.  And querying a deleted object returns, what used to be bound there, even though that name may refer to a completely different object than the one that is actually bound.

-- Kenneth Waters