In a previous article I already showed how large diagrams can benefit from layout algorithms. Netron was at the basis of the pretty pictures in this article and it was fairly easy to port the code to WPF, though WPF has some threading intricacies:

• Although the BackgroundWorker helper class is supposed to help in using non-UI threads in your application, it did not perform as expected on various occasions. Here I was unable to trace the source of the problme…threading issues are in general horrendous to pinpoint.
• The Dispatcher object is your friend when it comes to marshalling modifications from a thread to the UI-thread. The mechanism is easy to use but it can be at times difficult to access the Dispatcher when your architecture is based on a MVC (read: whatever pattern acronym you have chosen to build your WPF application) pattern.
• There seems to be at times a difference between using the Dispatcher you get from the UI elements and the one you access through the Application.Dispatcher property.
• In general, you should minimize the stuff you perform in a BeginInvoke call to keep the Dispatcher queue lightweight.
• Is it possible to access a property rather than a method through the Dispatcher? Can one change the location of a UI-element through the Dispatcher? I haven’t been able to to that, which seems to be a rather crual constratint sometimes.
• The VS2008 just stops sometimes because some debugging optimization was ‘optimized away’! This occurs when you try to peek into properties of some objects in the non-UI thread.

There is no noticeable difference between using layout algorithms in WPF and in GDI, the positioning and handling of coordinates is similar. On the other hand, there is a big difference between the responsiveness of WPF. In the examples below I was able to lay out 1500 nodes in less than five seconds but altering the diagram or scrolling produces grinding sounds. Obviously the cause is in the usage of the Control as a base class and the heavy weight of carrying animation, databinding and other stuff which for large diagrams is usually less an advantage. Using the System.Windows.Shapes namespace of .Net would be a better choice for big diagrams and layout.

When it comes to diagramming there is always a choice between sacrificing features or sacrificing scalability. There is also the balance between making a general purpose control and implementing stuff for a particular target group. For example, if you are interested in HMI diagrams you are not interested in large diagrams and vice versa. As well as the choices in what to deliver as shape libraries. Because it’s really hard to enable users to create shapes without understand the API (or opening the source code) one has to deliver a common set of shape libraries, but of course everyone has particular needs. If you use Visio you can easily add new shape to libraries but I wonder whether the serialized shapes are just groupings of predefined elements or really standalone blocks. In that respect one can consider grouping of basic shapes a good solution for a wide audience. I think, however, that for custom diagramming solutions and integrations one inevitably flows into custom code and custom diagramming controls. Diagramming software cannot be separated from consultancy unless you constraint yourself to the average (common) needs.

But anyway, in April 2006 I produced large diagrams in Netron and here they are again but based on pure WPF code. The first screenshot  represents randomly generated nodes on the diagramming surface.

The radial produce in less than three seconds a beautiful set of concentric nodes:

The balloon tree layout produced a rather dispersive diagram is the same time span:

Finally, the force directed layout produced the expected organic layout in tick more than five seconds: