[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Lifetime of WebGL objects in Firefox and Webkit
On Jun 27, 2011, at 11:15 AM, Kenneth Russell wrote:
> On Sat, Jun 25, 2011 at 4:48 PM, Vladimir Vukicevic <email@example.com> wrote:
>> On Sat, Jun 25, 2011 at 2:37 PM, Benoit Jacob <firstname.lastname@example.org> wrote:
>>> 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.
> Correct. The behavior in the spec was decided upon to avoid
> dependencies on the garbage collection algorithm or implementation.
>>> 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
> We could replace that last sentence with a link to the section (3,
> "WebGL resources") describing object lifetimes, in order to reduce
> duplicated text in the spec.
> This rewrite sounds fine to me. Anyone else? Note that this change
> would need to be made to all of the delete calls' documentation in the
Sounds fine to me.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: