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.
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.
Well it’s a dirty trick for sure, and I wouldn’t recommend it to anyone :)
On Tue, Nov 8, 2016 at 10:45 AM, <firstname.lastname@example.org> 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?
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" <email@example.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.
On Fri, Nov 4, 2016 at 1:45 PM, Kenneth Russell <firstname.lastname@example.org> 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.
On Fri, Nov 4, 2016 at 10:28 AM, <email@example.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?