We have a branch (of Cryptovoxels) that loads ktx compressed textures. We’re loading the .dxt.ktx directly (on desktop), not using basis. It works well, we have less stalls caused by glteximage2d, it runs really smoothly, and it uses half the GPU ram for the same scene - which is a fantastic result. We haven’t migrated all our textures to compressed yet, so we expect to see more gains over time.
The problem is that the GC will kick whenever the browser decides and you have no way (to my knowledge) to control that…
The decompressor can consume 2x more memory as part of its normal working and the browser is free to not reclaim this memory if not necessary. For eg, if you still have enough free memory even after the decompressor has finished working, no GC will occur. So, that’s not because you see more memory consumption when using the decompressor that there is something leaking: it’s only that the decompressor is using more memory to do its work and the browser did not reclaim it. Of course, it’s also possible there’s a leak somewhere but you can’t really know it by just looking at the memory consumption with and without the decompressor.
One way to know it for sure would be able to trigger the GC by hand to be sure all reclaimable memory is actually reclaimed, but I don’t think this is possible (even for debugging purpose).
For Chrome, it seems you can start it with the --js-flags="--expose-gc" parameter and then be able to use window.gc() to trigger a GC (I have not tested it).
Also, the trashcan button on the Performance tab should do a garbage collect when clicked.
Now I realize you may already have done this and noticed the memory increase after having triggered the GC by hand, in which case you can just forget what I have said above!
We also noticed that in Chrome, having the memory profiler running in dev tools was actually consuming a big chunk of memory and retaining it on refresh! We had to close dev tools, THEN refresh to clear it. It was throwing off our attempts to hunt down memory leaks.
Hey thanks for everyones posts here. The situation was way more complicated than I expected, and we’re still working on our profiling tools so we can work out exactly what’s going on. As a positive, we’re getting way less dropped frames due to textures being uploaded to the GPU, the world runs a lot smoother, and we get less OOM crashes on iOS. Massive job transcoding all our textures, but we got there. I’ll update this post once I work out what’s going on.