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

Re: [Public WebGL] WEBGL_lose_context



So Jeff, this should work?

var texture = gl.createTexture()
// put buffer, and upload it to GPU
texture = null;
// after some time that texture will be collected by GC?

Cheers,
Max

On 10 November 2016 at 22:02, Jeff Gilbert <jgilbert@mozilla.com> wrote:
There's no way to know from JS that a GL object is unused, but we do
track the WebGL JS objects and GC them when they are unused by both JS
and GL. (GL resources are freed when we GC them)

It's not a clean solution, but WEBGL_lose_context does give you a way
to very strongly hint to the browser that you want it to delete all a
WebGL context's resources. (Certainly in Firefox, loseContext()
destroys all child objects of the context, then tears down the actual
driver's GLContext as well)

In fact, when there are too many outstanding WebGL contexts active in
the browser (maybe many background tabs?), our method for controlling
resource usage is to force the oldest WebGL context to become Lost.
The code path used here is identical in Firefox to what's invoked by
`loseContext()`.

I'm not sure what the codepaths look like in other browsers, but
`loseContext()` is a byword for "release this context and its
resources" in Firefox.

On Tue, Nov 8, 2016 at 3:39 PM, Maksims Mihejevs <max@playcanvas.com> wrote:
> GPU resources have to be explicitly destroyed, as there is no way to know
> from browser if it is no more needed. Because references are simply -
> Number.
>
> If developer uploads texture to GPU, the only way to remove it, is by
> calling deleteTexture.
> There is no persistent object in _javascript_ associated with GL references.
>
> It is not poor design of WebGL, but just inherited design from OpenGL ES.
> Which not sure if anyone anticipated, that would be used not only in static
> environments, but in such dynamic as browser.
>
> Perhaps good way of destroying context with releasing all associated
> resources could be exposed to WebGL, especially with the nature of
> single-page websites.
>
> I assume it does it when you remove canvas element from DOM and GC all
> related to context data. Making sure it is not referenced anywhere in JS.
>
> Cheers,
> Max
>
>
> On 8 Nov 2016 5:22 p.m., <omarhuseynov97@gmail.com> wrote:
>
> Well it’s a dirty trick for sure, and I wouldn’t recommend it to anyone :)
>
>
>
> -          Omar
>
>
>
> From: Justin Novosad
> Sent: Tuesday, November 8, 2016 6:58 PM
> To: omarhuseynov97@gmail.com
> Cc: Jukka Jylänki; public_webgl@khronos.org
>
>
> Subject: Re: [Public WebGL] WEBGL_lose_context
>
>
>
>
>
>
>
> On Tue, Nov 8, 2016 at 10:45 AM, <omarhuseynov97@gmail.com> wrote:
>
> I’ve added WebGL context to the iframe element and then found out that
> refreshing that iframe page resulted in significant memory decrease in
> Chrome as I watched it using dev tools (garbage collection kicking in?). As
> far as I know, this is the only way of “deleting” WebGL context on Chrome
> (but I am still not sure as I’m not aware of what Chrome is actually doing)
>
>
>
>
>
> Hmmm... you need to determine whether that trick relies on specified
> behaviors.  Otherwise, this may very well be a trick that works today but
> not tomorrow.  Anyone here an iframe expert?
>
> -          Omar
>
>
>
> From: Jukka Jylänki
> Sent: Tuesday, November 8, 2016 6:19 PM
> To: Ryan Patterson
> Cc: Kenneth Russell; public webgl
> Subject: Re: [Public WebGL] WEBGL_lose_context
>
>
>
> I agree and have myself sometimes pondered about how to kill a context
> explicitly, and there's no way other than to release refs to all GL objects
> and leave it to the GC. It would be nice to have an explicit API, although
> the lose_context extension is not it (and shouldn't be), because it matches
> the resource loss semantics from the system, to solve another problem, and
> not the context itself. It would be nice to have a deleteContext() feature,
> since otherwise getContext()ing something effectively "taints" the <canvas>
> and ties it to that context type for its remaining lifetime, which is a bit
> messy. Not critical, but agree this is a bit dirty part if the API.
>
>
>
> On Nov 7, 2016 4:24 PM, "Ryan Patterson" <ryan.goat@gmail.com> wrote:
>
> Unfortunately I have been unable to find the deleteContext function in the
> canvas API.  Some implementations keep webGL contexts around even after all
> references are set to null.  The WEBGL_lose_context extension seems to be
> the only way to declare you are finished with a context and free the context
> resource itself in a deterministic manor.
>
> _____________
> Ryan Patterson
>
>
>
> On Fri, Nov 4, 2016 at 1:45 PM, Kenneth Russell <kbr@google.com> wrote:
>
> This deliberately isn't specified. If you're looking for a way to free your
> application's resources, you should use the various delete* APIs.
>
>
>
> -Ken
>
>
>
>
>
> On Fri, Nov 4, 2016 at 10:28 AM, <omarhuseynov97@gmail.com> wrote:
>
> It says the extension “WEBGL_lose_context” simulates webgl context loss.
> Does it mean the browser actually frees the resources on the GPU allocated
> by the webgl context or just pretends that it did?
>
>
>
> -         Omar
>
>
>
>
>
>
>
>
>
>
>
>