"... attempting to use a deleted buffer ...
produces undeﬁned results, including but not limited to possible GL errors and
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.3If a texture object is deleted while its image is attached to the currently boundframebuffer, then it is as if FramebufferTexture2D had been called, with a textureof 0, for each attachment point to which this image was attached in the currentlybound framebuffer. In other words, this texture image is ﬁrst detached from allattachment points in the currently bound framebuffer. Note that the texture image isspeciﬁcally not detached from any other framebuffer objects. Detaching the textureimage 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.