Memory leak: Texture dispose() method doesn't close ImageBitmap

[deenns]

Describe the bug

Currently, textures from glb files are loaded as ImageBitmap objects, which are not garbage collected by default - one needs to call the close() method

However, the Texture.prototype.dispose() method doesn't do it.

To Reproduce

1. Open https://gltf-viewer.donmccurdy.com/ in Chrome
2. Open the browser task manager (Shift+Esc or Menu -> More Tools -> Task Manager)
3. Find the tab in the task manager and see its memory consumption. It will be about 20-30MB.
4. Download this glb model with big 4K textures
5. Drag and drop the model on the viewer several times. You will see that the memory consumption rapidly increases, despite the fact all textures are disposed of each time

Expected behavior

The code texture.source.data.close?.() before texture.dispose() solves the problem.
But I would expect the Texture.prototype.dispose() method to do it automatically, especially given the fact, the textures are created by the gltf loader, and their type isn't obvious. Alternatively, a bool flag deep=true can be passed to the method to dispose of the inner resource.

If it's by design, it should be clearly written in the documentation.

Platform:

• Browser: Chrome
• Three.js version: r139

[Mugen87]

Texture.dispose() is intended to clean up the WebGL resources allocated by a texture. The problem with calling ImageBitmap.close() is that it invalidates the data source and makes the image bitmap not usable anymore. However, users could create another texture with the same image bitmap at a later point. If the image bitmap has already been closed, the following WebGL warning occurs:

WebGL: INVALID_VALUE: texSubImage2D: The source data has been detached.

So it's actually better if the image bitmap is managed on app level. Otherwise the engine has to make assumptions which are not necessarily true for all users.

To clarify this topic, we could add a note here in the Textures section: https://threejs.org/docs/index.html#manual/en/introduction/How-to-dispose-of-objects

[deenns]

Yes, following the same logic because of which material.dispose() doesn't dispose of textures, ImageBitmaps should not be closed (although for me it would be ideal to dispose of all the hierarchy with one method call).

I suspect that GLTFLoader didn't use ImageBitmaps before, so this case isn't handled in the viewer
https://gltf-viewer.donmccurdy.com/
The same happens here https://modelviewer.dev/editor/ (but I haven't read the code in this case, I just see increasing memory consumption).

@donmccurdy @elalish I think you should know about this problem.

Thus, yes, it should be mentioned here:
https://threejs.org/docs/index.html#manual/en/introduction/How-to-dispose-of-objects
And also here:
https://threejs.org/docs/index.html?q=Loader#examples/en/loaders/GLTFLoader
In the Textures section. Because when one creates an ImageBitmap manually it's obvious that it should be closed, but when it's created by the GLTFLoader, it's not obvious at all.

[donmccurdy]

@Mugen87 perhaps we could put a .dispose() method on the Source class, which would dispose of CPU-side data if invoked? Texture.dispose() would not invoke that, but the user could optionally do so.

[Mugen87]

Um, I'm not sure about that. dispose() does normally only free WebGL/GPU related resources. For the moment, it might be more clear if users know they are using ImageBitmap and let them handle the disposal on app level.

For the future, we probably have to rethink the design. ImageBitmap will be the default in context of image data at some point and a proper resource management by the engine would be desirable.