-
Notifications
You must be signed in to change notification settings - Fork 423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilization #2
Comments
Thank you Jeff! Yes, the renderer monitors user input and restarts layout whenever user drags a node or graph is modified, this is by design. You can stop the renderer at any point of time with renderer.pause() method. Would this be enough? Or do you need to permanently stop layout? |
Oh, so the layout will stop on its own after a period of time? That works... I thought it just kept on going with no limit on the number of iterations. :) |
Yes, layout stops if algorithm's parameters are chosen properly for particular graph. The renderer notices little movement of the nodes and stops layout cycle. But with certain parameters the system will never find it's energy minimum, and will keep bouncing nodes on the surface. For this case it's a good practice to let user pause cycle manually. It's the reason why renderer.pause() method exists :) |
First off, great piece of software.
It would be nice to add some stabilization parameter, so that it stops calculating the force directed layout. Perhaps it restarts if a node is moved, then stops again when it stabilizes. Problem is.. if you leave the graph open in a browser tab, it continues to consume CPU. My box is almost currently flat lined as it continues to process a layout that's stable.
Admittedly, I haven't looked to see if I can put a cap on the iterations, so this may just be my fault. :)
The text was updated successfully, but these errors were encountered: