Walter, hope you aware that we were trying to load minimum of 20000 nodes and 50000 links, and we receive “page unresponsive” error message and does not load too. Now we have come to the conclusion that we will logically group the nodes so that it would initially draw less number of nodes and links, there after by expanding the group would probably see the nodes that are there in the group.
I need your help on grouping the nodes with in a swimlane. For example, look at the below diagram, where I want to STOR001, STOR002 and STOR003 into one group and show a single node initially, on click of expand button it would draw the above nodes. Will this solve our problem? The idea here is instead of drawing 20000 nodes and 50000 links, we might be end up drawing only 200 nodes and 400 links initially. So I would not get “page unresponsive” error.
Can you confirm if I go with this approach, the GOJS will draw the nodes only when I click on group expand button. Not draw it & hide it initially, and than show it later.
Yes, you can control how many Nodes and Links there are at any given time. There are several approaches here, and you could use all of them in one app.
First, you can control how many data objects there are in your model. If there’s no chance that any code on the client needs to know about or manipulate the data, don’t send it to the client.
Second, even if the model has a lot of data in it, your app doesn’t have to create Nodes and Links for all of them. This is demonstrated in the “virtualization” samples:
But note that virtualization requires non-trivial effort to implement and imposes restrictions on the functionality that you might need to compensate for.
Third, I suppose you could have all of the possible Nodes and Links exist, but many could be not visible because they are effectively hidden by a collapsed tree or a collapse subgraph (group). That will certainly work to have good drawing performance, but your app will still suffer from a long start-up time, since it still needs to create all of those Nodes and Links in memory, even if they are never drawn.
Fourth, you could just have collapsed nodes or groups and create them when the user expands a node or a group. This is demonstrated by Incremental Tree (and maybe others?) where the first time the button is clicked the code actually adds the node data and link data to the model.
Walter, As I told earlier, we have enabled group nodes in the diagram. On click of a group node, it gets expanded and shows the sub nodes with transitions. However when the links are above 14000, we still get the “page unresponsive” error message.
Could you help me further to avoid this error message?
I have attached the screenshot for your reference.
I still do not understand the structure of your diagrams. Is each horizontal “lane” implemented by a Group, whose members are the nodes within that lane? Or have you implemented an override of LayeredDigraphLayout.commitLayers, just as the Layer Bands using a Background Part sample does? What Layout do you have for the whole Diagram, and what layout do your Groups have?
The idea behind “swim lanes” is that the general “growth” of the subgraph in each group/lane stays in the lane. After all, in a real swimming pool swimmers are not expected to cross lanes often. That’s why the Group.layout determines what happens in each lane.
But it appears that the general growth is upward (or maybe downward, I can’t tell) whereas the lanes cut across the diagram. Really there is only one layout, the Diagram.layout, which is typically either a TreeLayout or a LayeredDigraphLayout for all of the nodes and links in the diagram. There is no need for groups because you do not want to perform a separate layout for each group/lane.
So you really should begin with the Layer Bands sample that I mentioned in my previous post, Layer Bands using a Background Part, use a TreeLayout or LayeredDigraphLayout as the whole Diagram.layout, and override the commitLayers method so that you can set up the lane objects the way that you want.
Caution: LayeredDigraphLayout, particularly in JavaScript as opposed to .NET or Java, is very slow compared to TreeLayout. The former is effectively limited to a few hundred nodes and links; the latter can handle tens of thousands.
