Sadly I’m back with another issue regarding memory leaks, this time concering your spine library. We noticed that we still have quite some memory leaks in our projects, and on further investigation, we noticed that our spine entities do not get freed in the memory. I used the same project I posted last time, added two new scenes with one spine object each and you can switch between them.
I used the Memory Allocation Timeline to look at the memory, which looks like this:
Each spike represents the total newly allocated memory when changing the scene. After changing the scene again, part of the spike becomes grey, which displays how much memory was freed, while the blue part represents the memory that still stays allocated and cannot be freed.
I then took a closer look at what kind of objects couldn’t be freed:
The top two types of object (“Func” and “t”) regarding their retained size are all linked to the spine object.
We are working quite a lot with spine in our games, so leaking about 0.5 MB (depending on the complexity of the spine of course) per spine object everytime we switch a scene is quite a lot. It would be awesome if you could take a look at this.
I followed Dexter Deluxe’s topic and read your points, but I don’t think this is a VRAM related issue. The timegraph shows, that new memory gets allocated each time I switch the scene. The VRAM though should stay the same size once all assets are loaded.
Concerning the unloading of assets: Do assets contain references to the objects which use them? Do we really need to unload the assets in order to free entities? Seems a bit far fetched though, and doesn’t sound like a good design
From quick glance, looks like there is subscription to assets change events, but when related entity is destroyed, it does not unsubscribes from such event. So keeping reference to entity (scope for event handler) in assets _callbacks. This prevents from entities being freed.