PrimaryFeather
commented
6 years ago Thanks a lot for the report!
You are right, this is something that needs to be fixed inside the AssetManager. It should recognise it when you load another font with the same name, and dispose the old one.
In the TextField class, I think the behavior is fine. The class that created the BitmapFont is responsible for disposing it. So even when another bitmap font with the same name is registered, I think the old one should not be disposed automatically (you never know, perhaps the developer wants to reuse it later, and is just keeping it in memory).
Until that is fixed, please manually call TextField.unregisterCompositor to free up the memory. I will fix this, of course, but just so you have a workaround. :smile:
I'm not sure if this is considered a bug or just poor coding on my part, but this could be a potential issue for some starling users.
I have been working with the Asset Manager and have kept an array of any texture/assets loaded into memory. I have discovered that, loading a bitmap font through the asset manager will actually register the bitmap font, and remove the bitmap font texture (as it's not longer needed).
The problem with this is that if I was to add that same font back in the asset manager again, it adds that bitmap font all over again, and the GPU memory of the application rises. It does not seem to remove the previous bitmap font of the same name.
Is it possible that starling does not prevent re-registering fonts with identical names over and over again, or am I perhaps missing something? I changed my code to only ever add the bitmap fonts at the start of the application, instead of trying to add them whenever they may have been needed. This resolved a huge GPU memory increase as I was actually re-registering the same bitmap fonts over and over.
Original post: https://forum.starling-framework.org/topic/accidentally-re-registering-bitmap-fonts-can-cause-gpu-memory-increase