I have created a node with a sprite and when I use child.removeFromParent() on the node, although the node does disappear, I can still access to its contents such as the position of the sprite. I am worrying about what if I create many nodes and delete them immediately.
Would that cause a memory leak? Or how can I completely delete a node in Cocos2d-js?
I think cocos use an intern gc so maybe the life of an object lasts a bit after removing.
Also you can use retain/release to manually managing the object.
Retain when you create it and release when you delete it after a removeChild.
Try removeFromParentAndCleanup(cleanup) instead
Related
I am working on html canvas . I have implemented following features:
1) Simple Draw
2) Erasor
3) Shapes Draw
4) Shapes Resize
5) Shapes Move
6) Color Select
Now, I want to add undo/redo functionality.
Considering the above features implemented, I am thinking saving instance of entire canvas on every event execution. For example, on doing a shape resize, I push the entire canvas instance into an array.
When user clicks on undo, I simply, pop the last element from array, and repaint the canvas.
But, I am thinking saving the entire canvas instance everytime will be memory intensive and also not very optimal performance wise. Also, with this approach, I will have to limit the maximum number of undo/redo allowed. What would be the ideal number of undo/redo should I keep if I go ahead with this approach. Also, is there a better approach for this considering the above features.
Use the command design pattern, and redraw your canvas from your history of commands. You will be able to save a large amount of steps (hundreds if not thousands).
In a nutshell, instead of drawing to canvas directly, you will wrap your operation in a command that is added to a list, and then executed. When the user wants to undo, you remove the last operation from the list, and replay it. You can also keep the list intact and update an index marker to allow for redo.
In your case, you would also have commands for tool selection, so the selections would also be 'recorded' into your history.
Once you start using this pattern, you may find your entire application would be better structured using a state object, wrapped in a store that uses commit operations for all access. Then you get the undo-redo for free. See redux, vuex, and flux for the de facto standards of this store design. As powerful as these libraries are, they are really lean and quite simple.
https://en.wikipedia.org/wiki/Command_pattern
An alternative to the command pattern is the Memento pattern where you simply store the current state of the canvas every time an action is done. This requires more memory and generally will need to be restricted to small number of edits. Restoring an earlier state should be pretty fast though.
In cytoscape.js, is there a way to actually delete a node from memory completely? I wrote a layout and it consolidates nodes by making new ones and adding them to the graph, but if the layout is re-run, then I need to remove those nodes and recalculate, but there doesn't appear to be a way to allow these nodes to be garbage collected.
If there is a way to do this or is there another way I should approach this?
Thank you.
JS is a garbage collected language, so it suffices to drop all your own references to the node. If you remove a node from a graph and don't have any of your own references to it, then the garbage collector will clean it up sooner or later.
See also https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management
Is there best practice or recommendations for cleaning up canvases (or canvi!) after you're done using them?
In particular, I have multiple canvi (off-screen) with multiple dataURLs (also off-screen). After manipulation, I generate a final image and no longer need the old dataURLs, etc.
Does it make a difference for me to go through each item setting them to null or ''? I'm already using anonymous vars for the canvi and dataURLs... Wondering if it's overkill or not.
The garbage collector will reclaim the memory of any javascript variables when they go out of scope.
This includes html elements which haven't yet been added to the DOM.
You can force an object to go out of scope by setting all references to it to null.
If you use multiple offscreen canvas elements, you can save memory by reusing any canvas elements that are no longer needed.
I have an Ext.tree.TreePanel used with AsyncTreeNodes. The problem is that initially the
root node needs to have more than 1000 descendants. I succeeded at optimizing the DB performance, but the JavaScript performance is terrible - 25 seconds for adding and rendering 1200 nodes. I understand that manipulating the page's DOM is a slow operation, but perhaps there is some way to optimize the initial rendering process.
You could create a custom tree node UI that has a lower DOM footprint. In other words, change the HTML that is used to create each node of the tree to some less verbose (and likely less flexible) HTML.
here are some references for doing that:
http://github.com/jjulian/ext-extensions/blob/master/IndentedTreeNodeUI.js
http://david-burger.blogspot.com/2008/09/ext-js-custom-treenodeui.html
Enjoy.
I don't think you'll have much luck optimizing a tree with that many nodes. Is there any way you could use a grid to deliver the information? You could at least set up paging with that, and it would probably be a lot faster. You could also implement the row expander UX on the grid, which behaves like a tree, sort of, for each row.
I'm trying to optimize a sortable table I've written. The bottleneck is in the dom manipulation. I'm currently creating new table rows and inserting them every time I sort the table. I'm wondering if I might be able to speed things up by simple rearranging the rows, not recreating the nodes. For this to make a significant difference, dom node rearranging would have to be a lot snappier than node creating. Is this the case?
thanks,
-Morgan
I don't know whether creating or manipulating is faster, but I do know that it'll be faster if you manipulate the entire table when it's not on the page and then place it on all at once. Along those lines, it'll probably be slower to re-arrange the existing rows in place unless the whole table is removed from the DOM first.
This page suggests that it'd be fastest to clone the current table, manipulate it as you wish, then replace the table on the DOM.
I'm drawing this table about twice as quickly now, using innerHTML, building the entire contents as a string, rather than inserting nodes one-by-by.
You may find this page handy for some benchmarks:
http://www.quirksmode.org/dom/innerhtml.html
I was looking for an answer to this and decided to set up a quick benchmark http://jsfiddle.net/wheresrhys/2g6Dn/6/
It uses jQuery, so is not a pure benchmark, and it's probably skewed in other ways too. But the result it gives is that moving DOM nodes is about twice as fast as creating and detroying dom nodes every time
if you can, it is better to do the dom manipulation not as actual dom manipulation, but as some sort of method within your script and then manipulating the dom. So rather than doing what is called a repaint on every single node, you clump what would have been your repaint on every single node into its own method, and then attach those nodes into a parent that would then be attached to the actual dom, resulting in just two repaints instead of hundreds. I say two b/c you need to cleanup what is in the dom already before updating with your new data.