Proof that GLTFLoader does not free memory in Safari that it frees in Chrome

[andrewhodel]

https://jsfiddle.net/n1vebmug/2/

Watch the Memory Timeline in Safari increase while Chrome frees the memory.

Screenshot from latest Safari Technology Preview.

[manthrax]

memory in the browser is GC’ed so if chrome is gc’ing it and safari is not… sounds like it might be a safari bug.

If you manually force a GC in the debugger… does the memory go down?

[andrewhodel]

Safari deallocates memory when the THREE JS GLTFLoader is not used to add and remove meshes.

https://threejs.org/examples/#webgl_test_memory

This is a THREE JS GLTFLoader bug.

[manthrax]

This is a THREE JS GLTFLoader bug.

That only happens on safari ?

[andrewhodel]

In the Safari browser, yes.

Do you not have a Macintosh device? I provided a URL that proves it in less than 50 lines of code.

[manthrax]

If its a bug that happens in safari, and not in chrome… I would guess that it’s a safari bug.

No i don’t have an ios device sorry.

[andrewhodel]

I think you aren’t talking about a web browser and are possibly focusing on the problem with THREE JS requiring the ECMA module loading system that doesn’t provide output regarding dropped network sockets.

The problem of the GLTFLoader doesn’t need any guessing, it is a matter of work in isolating each function call and tracking the memory that is not deallocated of each. You may be aware that those tools have not been developed in any form that is released and the manual process is tedious.

[andrewhodel]

There is also three.js/examples/jsm/loaders/GLTFLoader.js at b82693c62d8ae9761f18f14505445076d07732f4 · mrdoob/three.js · GitHub

Meaning that it is possibly a problem with THREE.TextureLoader as only the Safari browser uses it in GLTFLoader.

[andrewhodel]

Also, as this is Safari 18 meaning it’s possible that another Safari condition exists in THREE.

That is not a Safari bug.

[manthrax]

Ohh I see its an explicit fallback.

Related (?):

Safari memory leak when scene dipose and rebuid serval times

I have created a scene using THREEJS that loads GLTF files and image-format tile maps. When I repeatedly destroy and rebuild the scene(ensuring that each destruction removes DOM nodes and all relevant THREEJS objects), I notice that the memory keeps increasing in the Safari browser, but the same code performs normally in the Chrome browser. I have ensured that I properly dispose of all relevant resources when destroying the scene. [image] [image] The following is the core code of my destruct…

[andrewhodel]

Because he was using Safari 17 at the time and that’s the only condition that exists in GLTFLoader possibly.

[andrewhodel]

I am verifying that the isSafari logic three.js/examples/jsm/loaders/GLTFLoader.js at b82693c62d8ae9761f18f14505445076d07732f4 · mrdoob/three.js · GitHub does not happen when using Safari 18.

There are no other Safari conditions in THREE JS if only GLTFLoader is extra.

All of the responses before this comment are useless and only serve to confuse the reader.

[manthrax]

If you’ve identified a bug, perhaps you could report it on the threejs github issues?

Issues · mrdoob/three.js

[kpachinger]

Browsers vary in handling of comparison and GC. This is essentially a (not) hot loop with a (not) async race interval. Pardon my boilerplate. A bulletproof shim (or test suite) might push the expected Loader response to an array… such as with a SetTimeout (the global window).

So unique references are stored, and checked, and handled. Memory disposal is accountable(?) whether you load a file that takes >2 seconds, or load the file instantly from local cache. At minimum you would retain the records to trace a point of failure.

Obviously it is being overwritten in scope.

[andrewhodel]

It’s all in the same thread in the example I provided.

It’s all in a single thread regardless of execution order.

The only extra consideration is that there is a WebGL memory area alongside the main javascript thread that has an extra layer of function based abstraction to interact with it, this is why many people have problems with dispose.

The WebGLBuffer object does not define any methods or properties of its own and its content is not directly accessible. When working with WebGLBuffer objects, the following methods of the WebGLRenderingContext are useful:

[kpachinger]

That is why I suggested you define the scope, at least to test behavior at stages and validate expectations.

• I encountered setInterval using a reference to a global as opposed to the live value, which is a known (quirky) issue.
• You redefine new Loaders within interval scope but traverse the scene globally.
• You access objects by index, as opposed to name, which is not guaranteed.

My point as it pertains to Safari (and not GL) is to specifically address the individual steps and objects. These are known browser issues which may impact your memory problem in a loop, where overwriting a reference can easily be avoided.

[andrewhodel]

That’s what you are missing that is very important.

It’s chunks, not steps and scopes that allow the improvement when you are fixing problems.

If you think about it at that high of an abstraction, that beyond chunks, you just forget what you are doing and that is the prophecy of the memory problems.

[kpachinger]

I don’t offer holistic contention. I recall several concepts I altered in a similar setting. I don’t know how far you have travelled on your Three Journey, or if your Senior Developer can speak to the fact.