ImageTexture created from thread leaks memory on Compatibility renderer

[yukinogatari]

Tested versions

Reproducible in: v4.3.dev3.official [36e943b], v4.3.dev4.official [df78c06], v4.3.dev5.official [89f70e9], v4.3.dev6.official [89850d5]
Not reproducible in: v4.2.2.stable.official [15073af], v4.3.dev1.official [9d1cbab], v4.3.dev2.official [3524346]

System information

Godot v4.3.dev6 - Windows 10.0.19045 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3070 (NVIDIA; 31.0.15.4633) - AMD Ryzen 9 7900X 12-Core Processor (24 Threads)

Issue description

When creating an ImageTexture on a subthread while using the Compatibility renderer, the underlying data isn't properly freed when the resource goes away. As best as I can tell, this issue first appeared in v4.3.dev3 and is still present as of v4.3.dev6.

Additionally, loading the Image into memory on the subthread, then creating an ImageTexture using it on the main thread does not exhibit the same leaky behavior. (I am aware of the warnings against interacting with the GPU on a subthread, so I know that's probably the "correct" way to do this, but still.)

Compatibility:

Forward+:

Steps to reproduce

1. Run the MRP in v4.3.dev3 or later.
2. Go to the debugger's monitors tab and watch the static memory value slowly climb. Note that video memory and texture memory values do not rise with the static memory, suggesting it's the underlying Image data that isn't getting freed.
3. Change the renderer from Compatibility to Forward+ and run the project again.
4. Static memory remains constant, as expected.
5. Changing enable_thread at the top of main.gd to false also causes memory usage to remain flat, as expected.

Minimal reproduction project (MRP)

image-memory-leak.zip

[clayjohn]

This is most likely caused by our changes to WorkerThreadPool and resource loading. Thankfully I can report this has already been fixed for beta1.

I tested on 8e2141e and confirm there is no memory leak anymore. Most likely fixed by #90913 (as this looks like a duplicate of #89585)

edit: for posterity, I tested on dev2, dev3, dev6, and 8e2141e. I confirmed the bug in dev3 and dev6