canvasman 3 Report post Posted March 5, 2020 (edited) I am creating multiple sprites from same texture in PIXI v5, I have few questions: 1. When I am not going to use specific sprite anymore, do I need to remove the sprite from container with container.removeChild(sprite) before calling sprite.destroy()? I call destroy without arguments because I don't want to destroy the texture which I might use later to create more sprites. 2. What is the difference between calling container.removeChild(sprite) and sprite.destroy(without arguments)? Does the GC collect everything regarding the sprite in either way? (except the texture which is in the GPU memory). Thanks! Edited March 5, 2020 by canvasman 1 ivan.popelyshev reacted to this Quote Share this post Link to post Share on other sites
ivan.popelyshev 1078 Report post Posted March 5, 2020 1. destroy() in sprites are actually a over-, javascript GC will take it anyway just like any other object. It could be different if Textures had links to sprites (events, subscribe) but they aren't. You remove sprite from container and pixi forgets about it. 2. sprite fields are getting slaughtered and its not usable anymore, many things will just throw error when you try to use them 1 canvasman reacted to this Quote Share this post Link to post Share on other sites
canvasman 3 Report post Posted March 5, 2020 7 minutes ago, ivan.popelyshev said: 1. destroy() in sprites are actually a over-, javascript GC will take it anyway just like any other object. It could be different if Textures had links to sprites (events, subscribe) but they aren't. You remove sprite from container and pixi forgets about it. 2. sprite fields are getting slaughtered and its not usable anymore, many things will just throw error when you try to use them Okay! Regarding the #1 question, would you call both removeChild() and .destroy() in that order or only either in my case when you don't need to use that same sprite later? Quote Share this post Link to post Share on other sites
themoonrat 105 Report post Posted March 5, 2020 I'd just call destroy As part of the DisplayObject's destroy function, it has the following code, that removes itself from any parent it has if (this.parent) { this.parent.removeChild(this); } 1 canvasman reacted to this Quote Share this post Link to post Share on other sites
canvasman 3 Report post Posted March 5, 2020 7 hours ago, themoonrat said: I'd just call destroy As part of the DisplayObject's destroy function, it has the following code, that removes itself from any parent it has if (this.parent) { this.parent.removeChild(this); } Moonrat is the best! Thanks dude Quote Share this post Link to post Share on other sites
riccioverde11 3 Report post Posted January 6 Hello, does anyone know why removing children with .removeChildren() doesn't also trigger the .destroy() of those children? If it is by design, can anyone suggest a good pattern? Quote Share this post Link to post Share on other sites
themoonrat 105 Report post Posted January 6 It's by design, because I may have some children that I want to add to one parent one moment, then to another parent the next. If you went through each child, and called destroy, then that child will automatically remove itself from the parent, so maybe that's the better way to go? 1 riccioverde11 reacted to this Quote Share this post Link to post Share on other sites
riccioverde11 3 Report post Posted January 7 (edited) Well technically that's what I'm doing now. Although, what if I have children of children I'd like to destroy? Isn't there some API ready for this? Or should I just iterate? My use case in particular is: I have 2 main scenes (which i switch based on a condition). Both scenes, have along the pixi tree - nested at an arbitrary level - some components with observable properties and on destroy of that component i remove those observers. When I switch scene the idea was to removeChildren from it to "clear" the tree and free some memory, but by doing this, I'm not actually destroying every single instance, and some observer might still be alive. What's the best approach in this case? Edited January 7 by riccioverde11 Gave more context on the issue Quote Share this post Link to post Share on other sites
ivan.popelyshev 1078 Report post Posted January 7 the best approach is to 1. read source code 2. run memory profiling (take heap dump) and look whether it works for you correctly: which objects are referenced from root and how everything else - we can make advices but they dont guarantee that it will work for you Quote Share this post Link to post Share on other sites
riccioverde11 3 Report post Posted January 8 Mhm, thanks, I thought there was a standard for these kind of procedures, but I guess it's left to the dev what's best for himself. Thanks for the advice. 1 ivan.popelyshev reacted to this Quote Share this post Link to post Share on other sites