Jump to content

removeChild not recursive - is it memory safe?


trueicecold
 Share

Recommended Posts

Hey there

 

I've noticed removeChild only removed the element from the children array of its DisplayObjectContainer, and updated the stage reference, but what happens if a child is a DisplayObjectContainer itself? the element will be remove from it's parent children array, and have its reference remove, but what about its children? will they still occupy the memory?

Link to comment
Share on other sites

I doubt that...

PIXI.DisplayObjectContainer.prototype.removeChild = function(child){    return this.removeChildAt( this.children.indexOf( child ) );};/** * Removes a child from the specified index position in the child list of the container. * * @method removeChildAt * @param index {Number} The index to get the child from */PIXI.DisplayObjectContainer.prototype.removeChildAt = function(index){    var child = this.getChildAt( index );    if(this.stage)        child.removeStageReference();    child.parent = undefined;    this.children.splice( index, 1 );    return child;};

This is the part of the code that you are talking about. Since all children are nested in displayObject container in my understanding they will cease to exist with the parent displayObjectContainer. You could easily write a test scenario for it and look at the memory in chrome dev tools. 

 

IN MY OPINION CHILDREN DIE WITH THE PARENT OBJECT CONTAINER!

 

http://www.sevenative.com

Link to comment
Share on other sites

The removed DOC stays as is with children intact. You're just removing a branch from the tree without making changes to any further attached branches and leaves.

 

Pixi doesn't keep display objects detached from the stage in memory, so they're subject to normal javascript garbage collection. As long as you store them somewhere they can be reused and re-added to the scene.

Link to comment
Share on other sites

The removed DOC stays as is with children intact. You're just removing a branch from the tree without making changes to any further attached branches and leaves.

 

Pixi doesn't keep display objects detached from the stage in memory, so they're subject to normal javascript garbage collection. As long as you store them somewhere they can be reused and re-added to the scene.

 

I've done some tests, while trying to create a SceneManager, changing screen from menu to the game, to options etc... my stage has a root container that hosts 1 scene (DOC) at a time, which is the wrapper of the Scene.

When I remove this wrapper (moving to a new scene), I've noticed I could still use the removed wrapper (again, DOC) methods, properties and children...

 

So I've done a stress test - switching scenes 20 times a second. After 20 seconds or so, memory went up from 149MB to 1.5GB (tested on chrome)...

 

Am I missing something? Is there another step after removing the warpper DOC from it's parent?

Link to comment
Share on other sites

The wrapper staying in memory is just garbage collection doing it's thing. Pixi shouldn't store the wrapper anywhere, but because you're referencing it later it's kept around by the javascript engine.

 

If you're using Pixi text objects (maybe graphics objects as well) you need to manually destroy them. If you aren't using a recent version from the dev branch on github this is bugged though.

 

The best thing to do would be to take a look at the memory profile like hubert said to see what's eating up memory. (On chrome F12 -> profiles -> heap snapshot) Examples would help too.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...