Memory leaks, memory management

[florentpeyrard]

I open this issue because I can't reopen https://github.com/aframevr/aframe/issues/3779, closed although there are some serious issues which are not addressed.

A fix is still needed to manage Context lost, which can have various reasons, not only models unloading/loading (see above for another one, maybe others exist).

Regarding the models loading/unloading : pooling is not sufficient if you have many models. You have a limited quantity of RAM available at any given point in time, so you have to dynamically load only what you need right now and unload the rest. As mentionned here, I posted some more in depth analysis about this here. TLDR : I'm using a workaround for the time being, which is unfortunately failing to fully release the memory, so my app is still being exposed to memory overflow.

Also, in a SPA, when you navigate between pages all having their own scene, each scene is destroyed/created each time, as the instance they live in is created/destroyed dynamically, so the idea of keeping the same scene throughout the user experience doesn't work.

So far, I really enjoy programming with A-Frame but to me, memory management is the really big downside that makes the engine unreliable for building ambitious projects. Really hoping for enhancements.

[kylebakerio]

I'm running into this issue, which I suppose it means it's time for me to start caring about some optimization and performance, but I'm curious what the canonical approach to this issue is. I have found this, but off the top of my head it sounds like "a lot" to try to restructure all of my code so that it's possible to recreate my app that way--not to mention it's a networked app, and I don't know off the top of my head how to get that idea to play nicely with making a new scene, which I guess is what would have to be done?

Is there any way to get A-Frame to be more resilient in this kind of situation?

(for the record, I'm not destroying my scene, so that isn't relevant for me.)

[diarmidmackenzie]

I'm hitting this too.

Building a scene using Ammo.js physics.
Once the scene reaches a certain size, it seems to be prone for VR sessions to be randomly interrupted and returned to the 2D view, with the page refreshed.

Reproducing this with with the debugger attached shows nothing ontoward except for this warning in the console: WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

I don't see any obvious indication of a memory leak, though I'm not an expert in debugging Javascript memory usage, so maybe I just don't know what to look for.

From what I have read on this:

• Web GL context loss can legitimately occur for a variety of reasons, and should be handled cleanly.
• THREE.js is supposed to handle this transparently, but that doesn't seem to be happening.

Reading through the trail here... https://github.com/mrdoob/three.js/issues/11435

... I see some comments about cubemaps, and "the user will have to take care of some things", though I've not fully understood - seems to be about textures dynamically generated from teh scene, which isn't something I'm doing (my cubemap textures are just PNGs). https://github.com/mrdoob/three.js/issues/11435#issuecomment-316321271

I'm using cubeMaps for the first time. Could this be the cause of my problems?

This jsfiddle (linked from the THREE.js discussion above) offers an example of how to force a WEB GL context loo, which could be a good start for testing this... https://jsfiddle.net/hfj7gm6t/4284/