How to optimize loading of huge diagrams

Hello!

We faced with the following performance problem.

We need to load huge configurations on diagram (more than 4000 elements), and it takes a lot of time. As we see from profiler, the most part of time takes adding one node to the collection, like the following: diagram.Nodes.Add(node);

I've attached a screen shot from the profiler's window.

Is it possible to optimize somehow this code?

Seems each time when we add a node to the diagram, some "service" functions called - sorting etc. May be better to add all nodes first, and then perform all other operations with the full list of nodes?

//Dmitry

Hello Dmitry

There are some known performance issues with the DiagramSurface which will be greatly improved in the next version. One thing you could try is adding all the nodes to a DiagramModel first before giving it to the DiagramSurface. Another trick is to try simplify your node templates where possible. Reducing the UI Element count per node can help improve the performance. If possible, you could also consider splitting your diagram into smaller sub diagrams. Or group parts of your large diagram together and only load the sub diagrams when the user clicks on them etc.

Jason Fauchelle

Hello Jason

We tried adding all nodes to a diagram before givin it to the surface, but we didn't see tangible performance improvement. Also we tried to simplify our node styles where possible, but with the same result.

Could you please tell when can we get the next version with your improvements?

//Dmitry

Hello Dmitry

It will be a while before the next version is released, but I'll be talking with the team to see if we can push the priority up and release it sooner.

Jason Fauchelle

Hello Jason!

Any news for that issue? Could you please provide an information when the next version will be released? Next week, next month or ...? It is critical for us.

//Dmitry

Hello Dmitry

As a very rough estimate, the next version might be released early next year. I have been stripping the lower priority tasks from the next version so that we can release it sooner. I'll also see if we can make the next WPF Diagrams release higher priority than the Elements release which would allow us to release it even sooner.

Jason Fauchelle

Hello Jason

Is it possible for you to deliver only fixes of performance issues earlier than the official release? We would like to get them as soon as possible.

Or may be you could explain how we can fix this by ourselves?

//Dmitry

Hello

The next version is most likely going to be only a performance upgrade version so we can get it out for you as soon as possible.

Performance enhancements will not be trivial. There aren't any hooks for you to do the same level of performance upgrades that we will be delivering. If you wanted to implement a performance enhancement yourself, you could have 2 diagram models. The master model, and then a visual model. The visual model would be a cut down version of the master model and would contain the nodes and connections that fit within the viewport. You'd need to listen to the viewport of the diagram and add/remove elements from the visual model. I'd recommend waiting for the built-in performance upgrades though so you don't mess around with your model.

We'll keep you posted on when the next version can be released.

Jason Fauchelle

Hello

And what if we have a mini map that displays the whole diagram, can we see the performance improvement in that case?

//Dmitry

Hello Dmitry

We have some plans for improving performance of displaying large diagrams in a minimap. The main idea is to have a way to provide different styles/templates for nodes based on the zoom level of the diagram. This is actually something you can partially implement now, (although you may already be doing this to some degree). On your minimap, you can provide a different DiagramFormatter than the one used by your main diagram. In this formatter, your node templates would be as simple as possible. Try to cut down the number of visual elements on each node as much as possible. For example, if the diagrams are so large on the minimap that you can't read the text, then don't include a text block or content presenter on the node templates. If the nodes are rendered so small, you could probably get away with simply displaying them as colored rectangles. The default node styles include lots of controls such as the node movers, resizer thumbs, rotate thumbs and connection points. You could strip all these out by setting the Template property of the node styles. Let me know if you're not already doing something like this and need help with creating simplified node styles. Note that in the performance upgrade version, we'll provide some built-in functionality that will aid in doing this.

Jason Fauchelle

Hello

Ok, we are waiting for the performance upgrade version. But one more point I see when load diagrams is many messages in output like this:

System.Windows.Data Error: 40 : BindingExpression path error: 'FlowDirection' property not found on 'object' ''TopologyCreatorModuleDiagramViewModel' (HashCode=59629589)'. BindingExpression:Path=FlowDirection; DataItem='TopologyCreatorModuleDiagramViewModel' (HashCode=59629589); target element is 'ConnectionPointThumb' (Name='Connector'); target property is 'NoTarget' (type 'Object')

I'm not sure this is my bug, could you please help me, what can be the cause of it? Can it affect the performance?

//Dmitry

Hello Dmitry

Yes this can affect performance, but it shouldn't be too much.

I have not been able to reproduce this, so I'm also not sure if this is a problem at my end or your end. I have however added a data trigger in the default node style to suppress the most likely cause of the issue. This will be available in the next nightly build. Let me know if this does not resolve the issue.

Jason Fauchelle

Hello Jason

Unfortunately this does not resolve the issue. By the way, when can we get the release with fixed performance issues? Our customers complain that loading of diagrams takes too much time as well as switching between modules. They would like to get the fix as soon as possible.

What is your prognosis?

//Dmitry

Hello Dmitry

At the moment I'm going to say the estimated release date is 2 months from now. I'll try see if we can release a kind of beta version for you so that you can start working with the new version as each performance enhancement is made, rather than waiting for everything to be finished. This will allow you to get perf upgrades sooner, but this may still be at least a month from now. I've noted down to solve this binding issue with the performance upgrade version.

Jason Fauchelle

Hello

It is OK if we get a beta version with perf upgrades in a month.

//Dmitry

Hello!

We are still waiting for the beta version with the fixed performance issues, but for now we would like to implement the following feature: show a message to the user while diagram is loading and drawing, something like "Please wait. Updating..." :) But we don't realize how can we catch the moment when diagram is fully loaded to surface and when we should hide the message.

Could you please help us and point what event should we handle?

I'm not sure it was clear enough but I hope you understand me ).

//Dmitry

Hello Dmitry

There are 2 possibilities here:

1/ You are building the entire diagram model before using it to set the DiagramSurface.Diagram property. In this case, grab the next nightly build where you will find the new FinishedLoadingDiagram event on the DiagramSurface. You can display the message before you start building the Diagram model, then hide the message when you handle this event.

2/ You are setting the Diagram property of the DiagramSurface first and then building up the model. In this case, you can simply show the message before you set the Diagram property, and then hide the message after you've finished building the model. Parts of the diagram visual would be built as you add them to the model - so the visuals would be finished loading by the time the model is finished.

Whichever approach you use, you'll probably need to display the message using a background-worker or a separate thread so that it is not affected by the long loading time.

Jason Fauchelle

Hello Jason

I see the new event on the DiagramSurface, but it is not what we needed. I'll try to explain.

We have a topology tree of elements that we should display on the diagram. There can be a lot of different topologies and we keep them in XML files. When we load a topology from a file we create instances of corresponding nodes on the diagram by the following method: diagram.Nodes.Add(node);

If the topology is quite big and has several thousand elements, we cannot see the diagram right after the last element was added to the diagram, it takes some time to show the diagram (usually 20-30 seconds). And in that time the user cannot do any operations with the diagram and he don't realize what is going. So, the problem is to handle the end of "drawing" of elements, but not "loading" of the diagram.

And we don't realize how to catch the end of "drawing". Is it possible at all?

And another problem I faced. When I add elements to the Diagram instance and then set the Diagram property of the DiagramSurface to this instance, connections are not displayed on the surface. But I see them in the Connections list of the Diagram. It is strange.

BTW, are you still going to provide us the fixes for performance issues at the beginning of November? Is it possible to get them next week?

//Dmitry

Hello Dmitry

The FinishedLoadingDiagram event is supposed to be raised after the diagram has finished drawing. The name comes from the idea of "loading" the visuals.

Apologies that this event did not work for you. You may be setting this up in a different way than I thought. Are you loading the diagram in a separate thread? or are you loading the diagram in the main thread causing the application to stop responding? Are you adding nodes to the diagram before or after setting the Diagram property of the DiagramSurface?

The connections not being rendered in your scenario sounds bad. I have not been able to reproduce this at my end though. Could you please send a repro project so we can look into this further.

The performance improvements will be first available in about 3 weeks from now. It is taking a little longer than expected. I'll let you know as soon as the beta of the next version is available.

Jason Fauchelle

Hello Jason

I've tried the following different approaches:

1. Set the Diagram property of the DiagramSurface and then add nodes to the Diagram in the main thread - this works well but causing the application to stop responding.

2. Create a new instance of the Diagram class, add nodes to this Diagram and then set the Diagram property of the DiagramSurface to this instance - it can be done in the separate thread but in that case I see the bug I mentioned before - I cannot see connections on the diagram. I think I'll provide you a repro project but a little bit later.

In the both cases I see that FinishedLoadingDiagram event occures earlier than I can see the completed diagram. I think the problem is that the rendering is going in another thread, not in the UI thread, but the event is raised from the UI. Am I right? What do you think?

If it is really so, I'm afraid it is impossible to handle the ending of the diagram "drawing". No?

Anyway, I think the performance improvement can solve the problem - if the diagram is loaded faster, the window don't stop to response for a long time. But I still doubt about the minimap - we should load the complete diagram on it and as I see it takes a lot of time even though I've simplified nodes styles.

//Dmitry

Hello Dmitry

You are correct that threading is causing the event to be raised at the wrong time. This makes it difficult to catch the end of the rendering, but it may not be impossible. I'll wait until you can provide a repro project to make it easier to look into this more.

The performance improvements will certainly solve the issue. As for the minimap, we have plans for the DiagramSurface control that will help improve the performance of a diagram zoomed out to fit all elements in the viewport (like the minimap).

Jason Fauchelle

Hello Dmitry

Just a quick update. The performance enhancements are going well and are very close to being available to you. I've been testing with 4000 elements which so far can load between 3 to 10 seconds. We'll try get the initial version to you some time next week.

Jason Fauchelle

Hello Jason!

Great news! We are waiting the enhancements with impatience. Thank you.

Dmitry

Hello Dmitry

The initial version of WPF Diagrams 3.0 with improved performance is now available for you to start using. Please send me your email address to jason@mindscape.co.nz so I can send you the installer.

Jason Fauchelle

Hello Jason

Did you get my last email with information about email address?

I cannot see any response from you. Did you send me the installer?

//Dmitry

Sorry Dmitry

Your email got swallowed by the spam filter. I've sent the reply email to you now.

Hello Jason!

Thank you for the installer.

I have tested the new version of WpfDiagramming and have the following questions:

1. As I understand, I can get the loading improved if I first load the diagram to some instance of the Diagram class and then set the Diagram property of the DiagramSurface to this instance, right? If I load diagram to the instance that already binded to the surface I see performance degradation. That's ok, but if I load the diagram and then set the Diagram property, I see nodes that should be rotated (they were rotated before saving) displayed incorrectly - the node is rotated, but connection points are not. Please see the attached picture for explanation. I'm setting the Rotation property to the nodes after adding them to the diagram, but before setting the Diagram property of the surface. I think I can set the Rotation property after adding the Diagram to the surface (loop for each node and set), but seems it can cause the performance degradation. Is it possible to fix it in your code?

2. I see that Resizer is not visible if I set the surface to readonly mode or if I set IsResizable property of the node to False. But I need to highlight someway nodes even if the surface is readonly or nodes are not resizable. I used the Resizer for that purpose before. Can I get something like "Selector" in the nodes template to highlight the selected node? I should be visible if the node is selected and hided in the other case. It may look like on the attached picture.

Generally I see the new version much faster than the previous one. But sometimes I faced with the strange behaviour - problems with the minimap, connection points were displayed separately from the node, hanging when panning... But I cannot reproduce them exactly, and I hope it because of the beta version. I need more time to play with the new version to evaluate it :)

Thank you again and waiting for updates.

//Dmitry

Hello Dmitry

Great to hear the performance is much improved for your application.

1. Yes, it is faster to build up the DiagramModel in code first before setting the Diagram property. This allows the DiagramSurface to perform bulk loads of rendering operations, whereas adding nodes to the Diagram of the DiagramSurface will cause each element to be rendered one at a time which can be especially slow on the minimap. We will fix the rotation issue and any other strange behaviors for the final release. - So you won't need to do the additional iterations of the nodes.

2. The selection element is a feature I would like to add to the framework, but I don't think we'll be able to get it into this version just yet. Regarding the readonly issue, you can set the ReadOnlyCanSelect property on the DiagramSurface to True to allow the resizer to still be display on selected nodes in readonly mode.

There are still some known issues that we will be resolving, some of which you have mentioned here. Will keep you posted with the next update.

Also, I noticed in your image you are using dropshadows on the connections. This is a WPF feature that can dramatically slow down the performance of your application. You should not have dropshadows at all on the minimap, and for the main diagram, you should at least remove the dropshadows when the diagram zooms out to a certain point where lots of connections can be displayed.

Jason Fauchelle

Hello Jason

Thank you for your advice about the dropshadows, we will change the style of the connections.

Concerning the nodes selection, as I understand we can use the ReadOnlyCanSelect property only when we have the surface in readonly mode. But in some cases we have the surface in editable mode, and we cannot see the Resizer either if we set IsResizable to False.

When are you planning to implement the selection feature in this release? And when are you planning to deliver the final release with fixes for the known issues?

//Dmitry

Hello Dmitry

The selection visual feature will not be in the final release of 3.0, but we can add this in a nightly build later this year or early next year. In any case, the ReadOnlyCanSelect property will also resolve your IsResizable scenario in the next update.

The final 3.0 version is almost finished which includes fixes to all the known issues. I am not sure exactly when 3.0 will be released as there is some marketing stuff that needs to be done. But if it takes long, I can get you an update of the msi so you can start using it sooner.

As for the rotated node issue you mentioned earlier, I wasn't able to reproduce your exact scenario, but I resolved a couple of issues that were similar. After I get you the next update, let me know if you still have that issue.

Jason Fauchelle

Hello Jason

Sorry, but I understand you not exactly, I think. Do you mean that the selection visual feature will not be included in the 3.0 version at all or it will be included but later?

Please send me the installer when the 3.0 will be ready.

And one more question. Initially I had the DiagramSurface with the grid (I set HorizontalSnapSpecifier and VerticalSnapSpecifier to {ms:SnapToInterval 10}). Then I set these properties to null to hide the grid. And saw that the navigation became faster. Is it possible to improve the navigation with the grid on the surface? Will you do it in the 3.0 release?

//Dmitry

Hello Dmitry

Version 3.0 has now been released which you can pick up from your account page: http://www.mindscapehq.com/store/myaccount

The selection visual feature is not in there yet, but this is on our list of things to add in a nightly build when we can. You can use the ReadOnlyCanSelect property for now to always show the resizer as a selection visual. This will also work when IsResizable is false in 3.0.

I have also noticed the background grid slows down the panning. This is something that I looked into improving for 3.0, but as this is entirely controlled by the WPF rendering framework, I didn't find a good work around for the performance issue here. The only way to resolve this performance issue is to not render a grid on your diagram. I have however put this on the backlog to have another attempt at improving this later.

Jason Fauchelle