GLTFLoader ImageBitMapLoader with Cache enabled causes memory leak

[Shane-oo]

Description

When using the GLTFLoader with a glTF that has textures, and with the three.js Cache enabled its possible to make the memory consumption grow until the client runs out of memory.

This seems to be because when the texture is loader the URL is randomly generated, therefore a Cache hit will never happen.

First load (5 image-bitmaps created):

Loading a different model:

Second load of the helmet (10 image-bitmaps created):

after many loads:

I first observed this on mobile as it only takes a few model changes for the memory limit to be reached and for the site to crash.

Reproduction steps

1. Using webgl_loader_gltf.html add line THREE.Cache.enabled = true;
2. Load the Damaged Helmet and take a heap snapshot
3. Load a different model e.g. the Cube
4. Go back to the Damaged Helmet and take another heap snapshot, and see that the Cache map has grown in size

Screenshots

No response

Version

r182

Device

all

Browser

all

OS

all

[Mugen87]

So the issues is Blob URLs are not stable. If you load an asset multiple times, the loader creates new URLs which eventually results in cache misses.

Problem is Base64 strings are no ideal keys because of their size so we can't merge #32987. Also it introduces unnecessary buffer to string conversion overhead just to make the cache work. Also other loaders than GLTFLoader are affected as well so the issue should ideally be fixed at a central place.

I think the most pragmatic solution is to don't cache blob URLs. A Blob URL does not have to be loaded over the network since the data are already at the client. We have to parse the image bitmap though but that is now necessary as well and not a blocking operation for the thread.