CAAT is leaking memory

[Arne Brutschy]

Hey,

I noticed that CAAT is leaking memory (its memory footprint increases
constantly over time). It seems to be related to the number of children
present; the more children there are, the bigger the increase.

Has anyone else noticed that? Has anyone experience with finding the
source of such a problem in Javascript?

Cheers,
Arne

[hyperandroid]

CAAT does not delete itself expired or out the timeline actors. You have to do so by calling container.removeChild or the methods available to manage the children list. You can instrument caat to take care of an actor by calling setDiscardable(true), which will manage an actor by removing it from its parent when it is expired.

Also make sure you are not leaking on your own, by registering observers and not removing them.

If you are already doing this, send me a simple test case if possible. Maybe memory is actually leaking ;)

Thanks for sharing.

- i

2013/5/16 Arne Brutschy <abru...@xylon.de>

--
You received this message because you are subscribed to the Google Groups "CAAT javascript framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to caatjs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Txemanu]

Hi all,

I also noticed a memory leak using cacheAsBitmap in an actor container with several child.

Maybe I was using it in a wrong way. The exact line that caused the leak is:

actorContainer.cacheAsBitmap(400, CAAT.Foundation.Actor.CACHE_DEEP);

regards

[hyperandroid]

Txemanu, I think that call does not leake at all.

CacheAsBitmap builds an image representation of an Actor. To do so, builds a new Canvas object, which is kept as its backgroundImage. By doing so, it prevents all its children to be animated/drawn but does not remove them. Simply does not use them to draw itself. So it is not a leak. It is a safe reference to its children which may be reused at a later time.

You could eventually call cacheAsBitmap (the 400 is the time at which you'd like to have the actor cached, so will be drawn at 400ms of virtual timeline) and then removeAllChildren to remove its children references.

Let me know if this is the expected behavior.

Thanks.

 - i

2013/5/16 Txemanu <txe...@gmail.com>

[Arne Brutschy]

Hello,

I can see that effect even when we aren't adding and removing children
dynamically. That is, we add all children during scene creation and
then we do not modify the scene afterwards anymore. Still, memory size
seems to grow, and the speed of growth seems to correlate with the
number of children initially added. (I haven't really measured this,
though.)

You can see the leak even in a simple demo such as
documentation/demos/demo3/sprites_org.html
It is small, but it is there.

To see this in Chrome, I activate the console, go to the tab "Timeline",
and click on the record button. The total memory slowly increases; in
this demo at about 10kB/second.

Arne

[Txemanu unamexT]

Yes, my idea was to have an actor container cached after creating the children (1 actor with custom paint function and 3 text actors)

Now that you mention, I have references to the children in custom properties inside the actor container (an own extended class)

so for sure they weren't removed properly, but also I had 28 actor containers from the begining and without add or remove them the

memory browser was increasing all the time.

Btw, I'll check it when I have time.

Many thanks for your comment.

2013/5/17 hyperandroid <hypera...@gmail.com>

[hyperandroid]

Txemanu,

post a test if you can.

Thanks.

- i

2013/5/17 Txemanu unamexT <txe...@gmail.com>