[Request] Create something like TexturePool

[b005t3r]

When doing custom rendering I often allocate temporary textures just to do some off-screen rendering and dispose them once they are rendered on screen - not the best approach, performance wise. I think Starling could provide something like a TexturePool class (something similar to AssetManager) for allocating temporary textures and returning them back to the pool when they are no longer needed.

I know this sounds like something that an extension could do, but Starling's performance could benefit on this as well. Filters could use this class internally, so many filters which use textures of similar size could use a single Texture instance instead of allocating a new one each. Also RenderTextures which use a second texture internally could all use the same instance when preserving previously rendered contents.

Just an idea, maybe not for the current version, but something to think about for Starling 2.0 :)

[PrimaryFeather]

Yes, I thought about that a little myself in the past. What I'm somewhat unsure of is how to handle it if a lot of textures are requested and then no longer needed. How do I (or a developer using Starling) know when to purge the pool? There's no warning about GPU memory getting low, after all. If I keep too many in the pool, the app could just crash.

But there might be strategies ... e.g. keeping them in memory for just a few moments. Then, when somebody creates / disposes textures in quick succession (think: changing TextFields), it would get it from the pool, otherwise it would get a new one.

The other problem are the different sizes of textures. If somebody puts a 256x256 texture in the pool, and someone else requires a 128x128 texture — should I return a subtexture of the big one? Then I'd need some kind of on-the-fly atlas creation, because then there are is now an "L"-shape available from that 256x256 texture.

All in all, this topic gets somewhat complicated when you dig a little deeper. ;-) Nevertheless, worth considering! Thanks for bringing it to my mind again.

[b005t3r]

Purging the pool is of course another topic - probably something similar to GC would be needed to get rid of textures which are no longer needed, setting the maximum amount of not-purgeable memory would also be an option.

As for different sizes, even without SubTextures this could work quite well - there's not that many POT-sized square textures after all :) With SubTextures you'd also have to add methods for fetching pooled textures for specific use cases, e.g. if you want a texture to be used as an input texture when rendering to a certain output texture, TexturePool would have to know what the output texture is, so it wouldn't give you a SubTexture created using the same parent texture as the output texture or its parent.

But these are the ideas of making it better, I think that even without purging mechanism and with only square POT-sized textures it would be really useful.