Huge memory leaks on text when destroy method is not explicitly called

[BrunoN]

Hello, I have done a simple simple code example to hilight some default behaviour that seem abnormal to me.

var renderer = PIXI.autoDetectRenderer(800, 600);
document.body.appendChild(renderer.view);
    var stage = new PIXI.Container();
    var text = new PIXI.Text('0', { font: '35px Snippet', fill: 'white', align: 'left' });
    text.position.set(20);
    stage.addChild(text);
    this.ind = 0;

    requestAnimationFrame(animate);

    function animate() {

        renderer.render(stage);

        var remove = stage.removeChildAt(0);
        //remove.destroy(true);
        var text = new PIXI.Text(++ind, { font: '35px Snippet', fill: 'white', align: 'left' });
        text.position.set(20);
        stage.addChild(text);
        requestAnimationFrame(animate);
    }
 

If you don't explicitly call the destroy method, you consume 3 mbytes of memory per seconds!

Seem weird to me that destroy method is not automatically called by garbage collector when there is no more reference on the text ?

Can someboy confirm the problem, or tell me where I am wrong?

Thank you!! Bruno

 

[mattstyles]

You're creating a new element per tick and adding it to the frame, the memory is always going to go up. Removing an element from the stage simply removes it, maybe you want to keep it to reinstate later, it should not be collected. Calling destroy is a separate operation which says 'I no longer want this, get rid of it, when you’re ready'.

A problem would be if destroying old elements did not reduce memory, but as it does, unless I am missing something, I'd say that was working perfectly.

Removing an element from the stage without destroying it is a perfectly valid thing to do, so that you could reinstate it into the stage later. It should be up to the user to remove and destroy those elements they no longer require, to free the memory. If the GC started destroying objects I want kept that would be a pretty serious bug with the GC.

[BrunoN]

Thank you very much for your immediate answer. Pixi is a great library I currently use it to develop a curves drawer..It 's very fast!

So , surely I was misguided how it works. When I use language like java or C#, allocated objects are Garbage collected when no reference stays on it. (Mainly the object is not refered by a list, or map for example or any...) it means the object is directly disposed without calling any method on it.

Reading your answer, it means in case of pixi, each object instantiated by a new operator has to be explicitly destroyed when I don't want to use it anymore (same than in not managed C++ for example)?

 

[rich]

Yes, and no  In the example above, like you, I would expect the Text object to be eventually garbage collected over time, because there should no longer be any reference to it, either within this script, or the Stage. However that isn't what's causing memory to spiral out of control. Each new Text object Pixi creates, it also creates its own internal Canvas to render the Text to. And it is these which are consuming RAM at an alarming rate, because they are only referenced by the Text object, they don't belong to it, they will remain in memory even when the Text reference is gone. The only way to remove them, is to call destroy. This cleans-up the Text object internally, and more importantly, purges its textures (which are what are taking up memory, the Text object itself is surely tiny in size, as it's just a bunch of data). There is no way you could expect a gc sweep to unbind and delete textures - C++ (etc) wouldn't do that either.