Cleaning up modules with new imageSheet API?

Solar2D General Questions/Discussion
#1

Just curious what other devs have discovered or revealed in regards to cleaning up (nil’ing) out image sheets and image groups using Director or Storyboard.

Jonathan’s blog post mentions that to clear image sheets, you should first remove all of the objects (children images) that use it, then nil out the sheet itself. But because the sheet isn’t part of a display group (i.e. Director’s “localGroup”), will Director catch and clear the sheet after clearing its child objects? Perhaps it’s no problem at all, and Lua will simply garbage-collect the sheet after the scene is voided from the Lua “package.loaded” table?

What about image groups? These can be inserted into display groups, so maybe Director will nil those out as it recursively cleans a scene’s “localGroup”. But if they’re not inserted into that display group (doing so is totally optional), then I wonder what will happen to them.

I know this whole new imageSheet API is very new and only part of Daily Builds, but I’m curious what (if anything) others have learned about using these with Director and Storyboard, and how specifically we can ensure that all traces are cleaned and cleared from memory on scene exit/remove.

Brent Sorrentino
Ignis Design [import]uid: 9747 topic_id: 23139 reply_id: 323139[/import]

#2

Well using storyboard for an example, you can use the destroyScene event to nil out the group after all the children have been removed, if needed. If I recall correctly you can do just the same with Director.

For image groups, as long as they’re inserted into the scene they should get cleaned up by either one automatically, since they retain the same removing methods universal to all objects/groups. If they aren’t inserted into the scene, then it’s just like a normal group that you didn’t insert into the scene… You have to be sure to take care of it like described above.

The rule of thumb is if it’s not inserted into the scene (like the sheet or the free group), it’s up to you to clean up after your code :slight_smile:
Unless I managed to miss something about this from that very long and detailed blog post :slight_smile: Hopefully that addresses your question! [import]uid: 87138 topic_id: 23139 reply_id: 92544[/import]

#3

@Revaerie,
Thanks for the tips. I did some actual testing on this today, and it appears that image sheets get removed from memory automatically… the Lua garbage collector takes them out. So, there’s no need to remove them explicitly in the Storyboard “destroyScene” as far as I can tell.

For my testing, I actually used Lerg’s “Director Slim”, not Storyboard. Using Director Slim, I loaded a scene which contained a complex image sheet with about 20 different frames. I printed the actual memory usage, borrowing the memory monitoring code from Storyboard (near the end, usually commented out). The core memory jumped up slightly when the image sheet was loaded (texture memory even more, which is expected). On scene clear, the memory dropped perfectly back to the level it was *before* the module and image sheet was loaded.

So, looks like we’re good to go… no need to clear this aspect of the new API! As for image *groups*, I haven’t tested that one yet… I’ll do that next.

Brent Sorrentino
Ignis Design
[import]uid: 9747 topic_id: 23139 reply_id: 92672[/import]

#4

And without further delay, my testing regarding image groups. :slight_smile:

Initial testing indicates: be VERY careful with these, if you use them at all. Even outside of Director, I’m having trouble getting image groups to clean up properly. I have followed the suggested advice of manually removing all children objects from the image group, then removing the group itself, then nil’ing it out. However, image groups seem to “lock” the texture memory from the image sheet they’re created with, and they won’t release it. Has anybody successfully gotten image groups to clear from memory as they’re supposed to?

Anyway, until we get further confirmation on this, I would suggest not using them at all. We also need more explanation of why these were even added to the API and what benefits they can really provide (I’m sure that will be upcoming in the official docs). Supposedly there are some nice under-the-hood performance benefits from these, but I think they’re very confusing to implement at this point. Hopefully this will be cleared up in the coming weeks…

Brent [import]uid: 9747 topic_id: 23139 reply_id: 92679[/import]