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

Re: [Public WebGL] Resolving OES_vertex_array_object issues

I should point out that for WebGL this means that most implementations will need to not call glDeleteBuffer when the user calls webgl.deleteBuffer but instead wait for all references to be released before calling glDeleteBuffer. Otherwise, according to the ES 2.0 spec

   "... attempting to use a deleted buffer ...
produces undefined results, including but not limited to possible GL errors and
rendering corruption"

ES 3.0 fixes this problem and requires buffers to be reference counted and usable past deletion just like other GL resources.

Chrome already does this
WebKit does not yet (yea, I know Chrome is built on WebKit but in Chrome we run our own GL)
I haven't checked Firefox


On Thu, Sep 6, 2012 at 11:15 AM, Brandon Jones <bajones@google.com> wrote:
I'm currently working on exposing the OES_vertex_array_object extension to Chrome, building on the work Ben Vanik did in Webkit. There is still an outstanding issue listed on the extension that should be resolved first, however.

Quoting from the spec:

The OES_vertex_array_object spec does not make it clear what happens to buffers that are deleted when they are referenced by vertex array objects. It is inferred that all buffers are reference counted.

Before OES_vertex_array_object there was no way to use a deleted buffer in a single context as the spec states it would be unbound from all bind points. After OES_vertex_array_object it is now possible to use deleted buffers.

Furthermore, the OpenGL ES 2.0 spec specifies that using a deleted buffer has undefined results including possibly corrupt rendering and generating GL errors. Undefined behavior is unacceptable for WebGL.

As implied by the above text, it seems as if the natural resolution is to require that buffers be reference counted so that a buffer that has been referenced by a VAO will not be removed even after DeleteBuffer has been called, though further attempts to bind to that buffer directly should fail. In my opinion this feels like the most straightforward solution.

Gregg Tavares pointed out to me that under this model the buffers should behave consistently with textures that are deleted while bound to a framebuffer:

pg. 114 section 4.4.3

If a texture object is deleted while its image is attached to the currently bound
framebuffer, then it is as if FramebufferTexture2D had been called, with a texture
of 0, for each attachment point to which this image was attached in the currently
bound framebuffer. In other words, this texture image is first detached from all
attachment points in the currently bound framebuffer. Note that the texture image is
specifically not detached from any other framebuffer objects. Detaching the texture
image from any other framebuffer objects is the responsibility of the application.

Which would mean that deleted buffers would be dereferenced if they are referenced by the currently bound VAO (including the default VAO) but not from any other VAOs.

The alternative is to immediately delete the buffers and generate an error when the user attempts to draw with a VAO that references a deleted buffer.

Is there any reason why we should prefer immediate deletion to a reference counting model? Either way it would be nice to resolve the issue in the spec so that we can make this extension available everywhere.

--Brandon Jones