Closed Scony closed 1 year ago
Yes, I understand why this is a problem. In the test that provided, the problem comes from banner_animation. The size change there forces that the BitmapTexture used for that layer has to be released (and sent to the pool) and a new one has to be created for the new size. So a new BitmapTexture is sent to the pool with every step of the animation. The change proposed makes sense.
In some cases like e.g. compositing alongside with
position
animations (see https://scony.github.io/stb-lab/expensive-compositing-3/index.html), theBitmapTexturePool
has a tendency to grow really fast if the textures acquired are large enough. This potentially causes a huge usage of GPU memory on the devices which recognize such a memory. This PR proposes a soft limit (limit that is obeyed approximately) which preventsBitmapTexturePool
from exceeding a certain number of total pixels stored in the pool. Moreover, it introduces an environment variable to control the limit.