[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Lifetime of WebGL objects in Firefox and Webkit
Thanks, Vlad and Ken, for the explanation. I understand that:
* The spec can't rely on when the GC gets triggered, as that's undefined.
* webgl.deleteTexture is the only way that we can ever offer to JS developers to ensure that a texture gets destroyed at a particular time before the context gets destroyed.
* We must communicate this much more clearly to JS developers than we have. I've talked to experienced WebGL developers who didn't know about that at all.
* Even though the spec doesn't require it, I am still very tempted to patch Firefox to have the WebGLRenderingContext no longer keep references to (non-bound) WebGLTextures, so that the video memory could be reclaimed at GC time. I understand that there are no guarantees as to when GC happens, but long-running WebGL demos are known to trigger the GC many times so this could reduce memory usage in practice. Correct?
----- Original Message -----
> 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:
> >> 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.
> 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
> > lifecycles...
> 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
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: