Editor: Memory leak when loading 4096x4096 texture several times

[RealTecWare]

Describe the bug

I tried to edit the MaterialsVariantsShoe.glb file from the KhronosGroup git in the editor and changed the normalMap and aoMap textures several times to a 4096x4096 texture.

I could use the same texture several times and the memory starts to increase after ~9-10 times (in my tests the value of changes sometimes were even smaller).
That causes the webgl context to crash after enough changes.

To Reproduce

Steps to reproduce the behavior:

1. Go to ThreeJS Editor
2. Import MaterialsVariantsShoe.glb
3. Change material to MeshPhysicalMaterial
4. Set the normalMap / aoMap >10 times to a 4096x4096 texture
5. The leak begins to grow after every following change

Expected behavior

After my analysis this only happens in 64bit browsers.
The following lines of WebGLState.js causes the increasment.

function texImage2D() {

	try {

		gl.texImage2D.apply( gl, arguments ); //After this function call the memory was increased highly and is only freed after closing or reloading the tab / browser.

	} catch ( error ) {

		console.error( 'THREE.WebGLState:', error );

	}

}

Screenshots

After 30 changes with the same texture:

Browser	Taskmanager Image
Vivaldi 32bit
Vivaldi 64bit
Chrome 32bit
Chrome 64bit

Platform:

• Device: [Desktop, Mobile]
• OS: [Windows, Android, IPadOS]
• Browser: [Chrome, Canary Chrome, Firefox, Safari, Edge, Opera, Vivaldi, Opera GX, Chrome for Android]
• Three.js version: r117 - r124

[mrdoob]

What happens if you load it more than 30 times? Are you able to crash the browser?

[RealTecWare]

I'm able to crash the webgl context with this, after the memory is over ~8GB (set the normalMap ~90-100 Times in my test).

[RealTecWare]

I have created a small example, where I simulate the situation. (~53 secounds - ~53 changes to the same texture)

If you use this example without ao change it only change the normalMap. (95 secounds - 95 changes to the same texture)

[Mugen87]

Can you please call Texture.dispose() every time you replace an existing texture? Meaning:

if ( child.material.aoMap !== null ) child.material.aoMap.dispose();
child.material.aoMap = texture;

[RealTecWare]

Thanks, that fixes the problem in my example.
Could it be that the editor never dispose the textures that are loaded?

[Mugen87]

Could it be that the editor never dispose the textures that are loaded?

Yes, I guess this is the problem. A quick search shows that dispose() is never used on a texture.

[RealTecWare]

The biggest question in my mind is at the end, why does the 64 bit browsers crash and 32 bit don't?
Maybe better garbage collection or less caching on the nativ side, because memory is a bigger thing with 32 bit.

But for now the problem can be solved by disposing and that's all what matters.