Deallocate textures from memory
- Dominant language
- TypeScript
- Stars
- 3k
- Forks
- 160
- PR merge metrics
- No merged PRs in 30d
Description
First of all, thanks for the great work done on this library. It's an amazing tool.
### _feature request / bug report_
Actually I'm not really sure if the behavior I'm seeing is expected for the library, but it's not the one I expected, so I don't know whether it's a bug report or a feature request.
#### library version
```
┬── gl-react@4.0.1
└─┬ gl-react-native@4.0.1
└── gl-react-expo@4.0.1
```
#### Expected behavior
After a texture is changed in the shader, the memory allocated for it will be deallocated, resulting in a smaller memory footprint, and thus avoiding memory related crashs (even if this means that a previously used texture will have to be reallocated for posterior use).
#### Actual behavior
Each time I change a texture in my component, the memory usage increases, only returning when the surface is finally unmounted (meaning the screen was closed).
#### Steps to reproduce the behavior
Just create a shader that takes a Sampler2D uniform and change it with something like a carrousel.
An example of the current behavior is in the profiling below:

The ramp A represents the initial rendering of the base image (the image that will be edited). This one is fixed.
Ramp B represent a succession of different group 1 textures being applied (Each application changes the old texture for the new one, resulting in only one group 1 texture being applied at any given time). After that, I left it static for a while.
Another batch of successive group 2 textures application came just after (one group 1 and one group 2 textures would be applied at any given time), resulting in ramp C.
At point D, the screen was closed.
What I was hoping is that a max of 3 allocations was sustained (one base texture, one group 1 texture and one group 2 texture). Is there any way that I can achieve this behavior? Even if I have to manually deallocate the texture.
Thanks in advance.
Contributor guide
Assessment
This issue has not been assessed yet.