Replies: 1 comment
-
Actually I may have stumbled onto what I'm seeing. Based on the settings I gave the layout the bbox was very large relative to what the circular bbox would be. Experimenting with the xGroupsOffset, yInGroupOffset, and yGroupsOffset more and I get a better results. I also see that I need to be careful and when I set itemSizesReference for each layout. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
One of the features we implemented is to click on a node and expand its neighbors. The neighbors are pulled by running a database query and pulling new graph data. The expand function is fairly simple and looks like this:
Setting the second import parameter to true means to merge the two graph which is implemented in graphology.
The main layout we're using is forceAtlas2 with a worker running in the background. I then implemented a layout selector that gets the new positions, sets all the nodes fixed to true to freeze their positions and animates the graph. For example, the circular layout function looks like this:
When forceAtlas2 or circular layout is applied the expand function works as expected where the new nodes are merged with the existing graph and then forceAtlas2 lays them out as usual.
However, I recently tested out the graphology-layout-tree as mentioned in #1478 (comment) using this function below.
The problem is that once I run this layout the expand functionality clusters all the new nodes together instead of spreading them out as with the circular layout.
This also happens when I run the dagre layout function I mentioned here #1477 (reply in thread)
Any idea why this occurs? One guess I had was the worker has issues with new nodes being added, but if that's the case I don't know why circular, random, and forceAtlas2 work just fine.
Beta Was this translation helpful? Give feedback.
All reactions