You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears that d3.js version 3.5.4 introduced a change which is causing force-directed layouts to initially stabilize much slower than before. Is this perhaps due to the release note on v3.5.4 "Improve initial random positioning of nodes for force layouts."?
I took the existing "Mobile Patent Suits" demo page (http://bl.ocks.org/mbostock/1153292) and modified it by adding 500 nodes to highlight the initial stabilization difference (see images below).
In both examples below, I stopped the layout prematurely at 0.6 alpha to show how far the layout has stabilized.
v3.5.3 is already very stable even at 0.6 alpha.
In v3.5.4, many nodes are still far out of range from center gravity.
From what I've tested in my own application, the chart is not only wildly bouncing around (more than in v3.5.3), but it overall takes a little longer to fully stabilize. This problem is essentially a blocker for us to upgrade past v3.5.3 due to the performance hit. The delay in getting to enough stabilization resembling a useful network is especially problematic for my application because we attempt to "Pause" the animation at certain alpha states, which now seem to be on a different scale (especially between .9 to .1) relative to v3.5.3.
I will add that another force-directed layout sample page does not appear to have this problem when I similarly add 500 nodes to the graph (http://mbostock.github.io/d3/talk/20111116/force-collapsible.html). I know that the Mobile Suits demo uses paths instead of lines to connect the nodes, and also has arrow head markers, but I've taken these out and they don't appear to fix the issue.
The text was updated successfully, but these errors were encountered:
Hello,
It appears that d3.js version 3.5.4 introduced a change which is causing force-directed layouts to initially stabilize much slower than before. Is this perhaps due to the release note on v3.5.4 "Improve initial random positioning of nodes for force layouts."?
I took the existing "Mobile Patent Suits" demo page (http://bl.ocks.org/mbostock/1153292) and modified it by adding 500 nodes to highlight the initial stabilization difference (see images below).
In both examples below, I stopped the layout prematurely at 0.6 alpha to show how far the layout has stabilized.
v3.5.3 is already very stable even at 0.6 alpha.
In v3.5.4, many nodes are still far out of range from center gravity.
From what I've tested in my own application, the chart is not only wildly bouncing around (more than in v3.5.3), but it overall takes a little longer to fully stabilize. This problem is essentially a blocker for us to upgrade past v3.5.3 due to the performance hit. The delay in getting to enough stabilization resembling a useful network is especially problematic for my application because we attempt to "Pause" the animation at certain alpha states, which now seem to be on a different scale (especially between .9 to .1) relative to v3.5.3.
I will add that another force-directed layout sample page does not appear to have this problem when I similarly add 500 nodes to the graph (http://mbostock.github.io/d3/talk/20111116/force-collapsible.html). I know that the Mobile Suits demo uses paths instead of lines to connect the nodes, and also has arrow head markers, but I've taken these out and they don't appear to fix the issue.
The text was updated successfully, but these errors were encountered: