[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Lifetime of WebGL objects in Firefox and Webkit
- To: Benoit Jacob <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Lifetime of WebGL objects in Firefox and Webkit
- From: Vladimir Vukicevic <email@example.com>
- Date: Sat, 25 Jun 2011 19:48:55 -0400
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=esAMX9to5xsdmOpQocDE0E2TTXYcotXdco5e6brk3AY=; b=HZKpB6bXXYBuGFfVH/hQGjT4d0eClBM7D/9m15SeFfYjpA1Hojd6Ya8PKNKa3s0h4X enZiOtIBFe4gcyTVzPfJxjSmVCPl7rcHaS9DN73DuT9tCEsmJDTKgBu0PQh42ibXkyPr gkLiyDJcTmdHPu84dmyPaMAze5KbSwBNEsYAk=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=d9UyeYwNCRj5ffG56K6MsPsLA3MaXybfEcKle/SG7vH0xvMW4q3HD1pa/45Xhs+uCV uoL0XIlDNhgBTLnG/zKVroFOYBQSfTMTTSgdorwEar6gU9wIW1Z1rWQD0mq7/ev3jx4C 6n43hcss2RoehD/1WLnTTe6kEewCeD5ScNVDk=
- In-reply-to: <788576513.337434.1309027073734.JavaMail.email@example.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <1076858097.337214.1309022066203.JavaMail.firstname.lastname@example.org> <788576513.337434.1309027073734.JavaMail.email@example.com>
- Sender: firstname.lastname@example.org
On Sat, Jun 25, 2011 at 2:37 PM, Benoit Jacob <email@example.com> 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.
> 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
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
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: