<>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:“Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:“”;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:“Calibri”,“sans-serif”;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:“Times New Roman”;
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:“Times New Roman”;
mso-bidi-theme-font:minor-bidi;}
<![endif]–>
(This is adapted from a new section in the next GoXamIntro document.)
If you can use WPF, do so: it is usually faster than Silverlight.
With small to medium size graphs, the load time and the interactive performance should be good. However, as your diagram gets to thousands of Nodes and Links, you will find that the load time may start to get long. Interactive performance should remain reasonable as long as the user does not zoom out so that most of the nodes are visible.
The load time is due to the overhead of creating all of the FrameworkElements of the DataTemplates. You can improve this initialization performance by keeping your DataTemplates as simple as possible. Reduce how many elements you use. Avoid using Controls. Avoid creating FrameworkElements that are not visible. Minimize the number of data-bindings too.
Interactive performance, typically for moving nodes, is reduced when the link Routes have Routing=”AvoidsNodes” and/or when Curve=”JumpOver” or “JumpGap”.
Some diagram layouts are faster than others. TreeLayout is much faster and scales up much better than LayeredDigraphLayout.
If you intend to handle many thousands of nodes and links, we recommend that you experiment. When showing such large diagrams your users may find it easier to comprehend when you use progressive disclosure or drill-down. The use of expand and collapse, for both subtrees and subgraphs, can help greatly too. Look at the IncrementalTree and Grouping samples in the demo.
If you have many thousands of nodes and links and you know ahead-of-time exactly where all of the nodes are located, you may be able to use the virtualization technique discussed below.
Of course virtualization doesn’t help if the diagram has to show all of the nodes anyway, either because they are all positioned very near to each other or because the diagram has been scaled down to show most or all of the DiagramPanel.DiagramBounds. That’s the expectation for the Overview control. If you can’t avoid using an Overview, customize the DataTemplates used by the Overview to be absolutely as simple as can be. This is usually easy to implement because the nodes will be so small that a simple rectangle or ellipse is sufficient.Finally, if you really need to deal with tens to hundreds of thousands of nodes, you may want to use GoDiagram instead. You can easily handle tens of thousands of nodes in GoDiagram for Windows Forms. Only layered-digraph layout is a serious limitation. But it requires much more coding to produce complex or pretty nodes and to integrate with data. In that respect using XAML in GoXam is much superior to GoDiagram.
Virtualization
There’s no inherent limitation on the numbers of nodes and links you can have in a diagram. However, 5000 nodes plus a similar number of links is probably too many for good performance in Silverlight. The biggest problem is the load time – Silverlight is inherently inefficient in creating visual objects, and FrameworkElements are heavyweight objects.
You should keep the DataTemplates as simple as possible.
Try to avoid using Controls in them.
Try to minimize the use of data-bindings.
Avoid creating invisible elements.
But if you don’t need to perform a layout on the whole diagram when you load it, then there might be an alternative. (Performing a layout would require all of the Nodes and Links to exist first, so that it would know how big each Node was.)
Here’s a GoXam sample that customizes the Diagram.PartManager to only create nodes when the Location is within the viewport. This will be included in the version 1.3 kit but should work in version 1.2.
WpfVirtualizingPartManager.zip
SilverlightVirtualizingPartManager.zip
This sample creates 62500 nodes and 62499 links in a grid arrangement. This sample works reasonably well in WPF, but it's not so great in Silverlight. You can easily adjust how many nodes and links it creates by changing the code. For example for 4900 nodes and 4899 links, use: const int max = 70;
The sample makes some strict assumptions:
- that each node data has a Location
- that each node DataTemplate data-binds that Location property (with any Mode except OneTime)
- that each Node is at most 100x100, but you should customize that code in ComputeNodeBounds
- if you want to use a GraphModel instead of a GraphLinksModel, comment out the line: #define LINKS
- if you want to use Groups use the line: #define GROUPS, and customize the code in ComputeNodeBounds to return the right value for your Groups
One trade-off is that scrolling and zooming is slower than when not virtualizing the PartManager. Most people would consider the vastly quicker load time (and reduced memory usage) to be worth it.