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

Re: [Public WebGL] Lifetime of WebGL objects in Firefox and Webkit



On Sat, Jun 25, 2011 at 2:37 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
>
> Hi,
>
> As far as I can see, in both Firefox and Webkit, the WebGLRenderingContext stores a hash table of reference pointers to all the WebGL objects associated to this context, such as textures.
>
> This means that unreferenced objects such as textures are kept alive until the WebGLRenderingContext gets destroyed. The only way to destroy a WebGL texture earlier than the context itself, is to call deleteTexture explicitly.

I think this is intended, and explicitly allowed by the spec.  There's
no real way to specify GC behaviour, so the only thing that can be
said is "at some point".  Code is explicitly encouraged to use the
delete* functions to better manage their own resources, because even
if browsers were to implement better gc semantics, they wouldn't be
perfect, and objects could accumulate until a gc actually happens.

> It's easy to imagine (admittedly bad) JS code that would inadvertently cause a leak because of that. ÂImagine a video player that would create a new texture object for each frame, let it go out of scope and naively expect that to destroy it.
>
> Should we implement a change making the WebGLRenderingContext no longer keep WebGL objects alive?

I don't think it's possible to do this; as I said, there's no way to
specify gc behaviour, and there's really no concept of "out of scope"
or anything like that... trying to define it is probably a rat's nest.

> The spec also says:
>
>> void deleteTexture(WebGLTexture texture) (OpenGL ES 2.0 Â3.7.13, man page)
>> Â ÂDelete the texture object contained in the passed WebGLTexture as if by calling glDeleteTextures. If the texture has already been deleted the call has no effect. Note that the texture object will be deleted when the WebGLTexture object is destroyed. This method merely gives the author greater control over when the texture object is destroyed.
>
> As a naive implementer reading this, my questions is "should deleteTexture actually call glDeleteTextures immediately?", the beginning of the above paragraph suggests so ("as if by calling glDeleteTextures") but the rest casts doubt on that: "Note that the texture object will be deleted when the WebGLTexture object is destroyed." This suggests that the texture object only gets destroyed when the actual WebGLTexture JS object is destroyed i.e. on the next GC after all references to it were lost. In any case, both Firefox and Webkit destroy the texture immediately in deleteTexture.

This is indeed confusing.  I'd suggest something like:

"Delete the texture object contained in the passed WebGLTexture as if
by calling glDeleteTextures. If the texture has already been deleted
the call has no effect.  This method is the preferred way to manage
texture object lifetimes.  Merely releasing all references to a
WebGLTexture object will cause it to be deleted at some point in the
future, which may mean anything up to and including context
destruction time."

I actually don't like the last sentence there all that much; do we
even need it?  (Or just delete the "Note that..." section in the
current text.)  We already have a separate section on object
lifecycles...

    - Vlad

-----------------------------------------------------------
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:
unsubscribe public_webgl
-----------------------------------------------------------