Hi,

Tracking a memory leak in my app using Director when I change screen, I tried replacing a movieclip composed of 8 images with a single image object. The GC count goes down significantly.

Of course, the moviclip is inserted into the localGroup used by Director right after being created.

So can someone confirm all images composing a movieclip are actually removed by Director like all display objects and related listeners? --my movieclip has a tap listener attached to it.

Ch.

At this point, the best advice I can give you would be to make sure you manually remove your touch (and any enterFrame listeners) attached to your movieclip object manually BEFORE scene change. This shouldn't be that difficult if you reserve a specific function in your module that handles the cleanup of such listeners.

Also, be sure to use a more efficient method of cleaning groups than what is found in director:

http://jonbeebe.tumblr.com/post/3760389212/proper-group-cleaning-in-corona-script-download

I have a modified version of Director that is more efficient, but doesn't currently work with some of the transitions. From the basic scene changes with no effects though, it works great:

http://developer.anscamobile.com/forum/2011/03/06/director-class-12-more-efficient-cleangroups-function

Hope that helps.

Jonathan Beebe

Actually, objects created with movieclip are nothing more than display groups with display objects within, so the first link might be just what you need to prevent all your leaks.

As an extra precaution, be sure to remove your touch listener from the object before removing it.

Well, I tried removing the movieclip listener then call Jonbeebe cleanGroup function before calling changeScene(), but I get no improvement: the memory leak still happens.

If I replace the movieclip with a single image, the memory leak disappears, so the problem clearly comes from the movieclip.

Do you think the problem will remain if I use Sprite instead of Movieclip?

Ch.

Perhaps not. I used to use movieclips a lot, but lately (after discovering the ease of use of TexturePacker), I'm switching to using spritesheets for all my animations.

So far I haven't noticed any problems, but I get more control over animations using spritesheets. I know when you call spriteSheet:dispose() it automatically removes all objects that use that same spritesheet... so you shouldn't run into memory issues.

Also, I've read that spritesheets are better for preserving texture memory and graphics drawing because only one image has to be loaded for multiple frames of animation.

Hey Jonbeebe,

Well, that was it! I replaced the movieclip with a spritsheet and the GC count stopped growing up!

Now, I have another problem =)

The GC count remains stable, but it doesn't get lower when I get back to previous screens. My app (an illustrated children book) has more than 25 screens so I'm afraid it's gonna be a problem when reaching the end of the book --so far, the GC count is around 800 when reaching page 12.

I removed listeners, timers and sounds, I emptied tables in the clean() function called by Director, but I guess something remains.

I'm suspicious about the sound, because I tried with and without the audio.dispose() function for all the loaded sounds, and the GC afterwards (ie. on the next screen) is exactly the same in both cases. I use audio.stop() before disposing of the sounds, so I don't understand why the GC doesn't get lower.

Do you have an idea of what the problem could be? Do I actually need to dispose of sounds when switching screen if they're declared as locals?

Thank you.
Ch.

I think audio, whether its local or not gets held in RAM unless it is disposed of and nil'ed out.

Regarding movieclips vs. spritesheets, I conducted an experiment recently that you might find really useful:

http://jonbeebe.tumblr.com/post/3862522959/texturepacker-review-absolutely-essential-software

It's a review of the TexturePacker software, but within that article is the results of an experiment that pitted spritesheets against movieclips using the same animation.

Spoiler: spritesheets blew movieclips away, by way more than I even expected. I'll be using spritesheets from now on.

Hey!

Sorry, I was quite busy this past week.

Very nice article that finished to convince me to buy TexturePackerPro --I bought it in bundle with PhysicsEditor; that's a bargain! =)

I made more tests with the audio part, like having a scene with no display objects except for a button to switch back to the main menu. Whether a large sound is loaded on that scene or not, when I leave this scene and get back to the main menu, the GC count is exactly the same. This means there's no memory leak due to the sound keeping the memory it occupied.

Now, since the memory keeps going up when new scenes are loaded --not when going back--, I made some tests with the size of the Lua files themselves and it seems the GC count is directly related to the size of the code of the scene itself (the .lua file). So, this would mean that although Director is supposed to unload the packages, it doesn't seem to really happen. Have you noticed this?

Ch.

I have read your review of Spritesheet and texture packer.

I was wondering if spritesheet vs moviclip match has something to do with image size, no ?
If I have 30 big images (250pix) trying to put them on one spritesheet is still a better option than movieclip ?

Don't know ...

@charlyp: Great observation, you might want to forward that to the Ansca team to see what they have to say about it... I'll also keep it in mind and see if I can find anything out about that.

@Antheor: I think if you have large images, it could possibly take more time to load that one big image especially if in your code you don't need them all at once. However, I think wait time would be minimal and might even be remedied by a simple loading message at the start of your screen.

I think spritesheets would still be better than movieclip in that situation, because instead of drawing images from scratch multiple times, you're only doing it once.

Spritesheets can also compress the overall size of the images with transparent edges while not affecting them visually in your app, so it would even take up less texture memory as well as being able to create objects quicker because the image is already loaded into memory from the get-go.

And just a quick note for everyone...

I have created an alternative to Director Class that I'm testing in my latest upcoming game. So far there are NO leak issues whatsoever. I have not included any transition effects, because I want to start small, keep it bug-free, and work my way up from there.

If it proves itself in this next game release, and I detect no leak issues, then I'll release it to the public. Either way, I'll release it at some point, so stay tuned...

jonbeebe, thx for your fast and clear answer.

And, thx again for working on great class you are willing to give to the public.
Memory management is indeed something hard for newbies like me (doing a proper remove is always getting me in troubles ... )

Well, I was pulling my hair out over this bug, but I think I have a solution for you guys.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

        g.oldRemoveSelf = g.removeSelf
 
        function g:removeSelf()
            g:stop()
            g:prepareDeletion()
        end
        
        function g:prepareDeletion()
                while(#animFrames>=1) do
                        table.remove(animFrames, #animFrames)
                end
                while(#animLabels >= 1) do
                        table.remove(animLabels, #animLabels)
                end
        end