This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, We are considering the new WPF Diagram 4. We have a few things that are super important to us and we want to check with you before we dive in:
Thanks! Gilad |
|
|
|
|
Hi Gilad, Thanks for contacting us about WPF Diagrams. Yes, the latest version of WPF Diagrams uses virtualization (introduced in version 3) so the visual elements for both nodes and connections will only be created when they are in the viewport. The initial load (and overall performance) will depend on the number of elements within the viewport. Initially setting the viewport to display all items, or zooming far out can cause performance lag. We provide an AStarPathfinder algorithm which in version 3 was updated to avoid connection overlaps. This can be enabled by passing in a desired connection separation value to the constructor of the AStarPathfinder that you use. This will be the pixel value between close connections at default zoom level. Note that it does not always produce perfect results, and the performance is slightly reduced compared to not enabling connection separation (default AStarPathfinder constructor). Here is a blog post about it: http://www.mindscapehq.com/blog/index.php/2013/07/31/wpf-diagrams-improved-path-routing/ Please let me know if you have further questions. -Jason Fauchelle |
|
|
|
|
Great! This sounds like a good start. A few more questions, is there a way to modify the path finding algorithm in some way? We'd like to have full control over the connections in case the algorithm isn't sufficient for what we need. Also, does Mindscape has any options to have a preview window (located on top of the diagram) that support navigation or panning over the main diagram? Gilad |
|
|
|
|
Hi Gilad, Yes, you can create your own pathfinder algorithms by implementing the IPathfinder interface. This has a FindPath method where you write your algorithm that returns a list of points that you want the path to follow. The method also passes the whole IDiagramModel which you can use to examine the state of the diagram to route the connections around nodes if you wanted to. You can use another DiagramSurface control binding to the same diagram model and have ZoomMode set to SizeToFit. This causes the mini-diagram to be zoomed and panned just right to fit the diagram visual. Note that if your diagram model is large, then this mini-diagram will be slow to render as it will try drawing all the nodes and connections. We don't have any optimizations around this. If this is an issue, one option would be to have 2 diagram models - your main one, and then a cut down one with stripped out detail that can be displayed in the mini-diagram surface. For example, you could represent several connections as a single connections. You can also create custom node styles for use in the mini-diagram that draws nodes in the most simplistic way such as colored rectangles. We don't have controls that would allow you to use the mini-diagram to pan the main diagram. I have however attached a sample project that demonstrates how you can display a rectangle on a size-to-fit diagram based on the viewport of the main diagram. To run this sample you'll need to reference the WPF Diagrams 4 dll, or you may be able to try with an older version. When it's running, add some nodes to the left hand diagram and spread them out a bit. Then, when you zoom and pan the left diagram, the dotted rectangle on the right hand diagram will reflect the viewport. You could reverse this logic to allow the dotted rectangle to be dragged to pan the main diagram. Let me know if you have further questions about this. -Jason Fauchelle |
|
|
|
|
Thank you so much. We will evaluate these features stosee f we can make the diagram feet our requirements. |
|
|
|
|
A sample project is attached. Hi, I'm currently busy evaluating your product in order to check whether it aligns with the requirements we have. One of the most important things to our customers is the speed (=performance) when dealing with large amount of items. Therefore - this was the first thing I looked into. What I'm noticing is an improvement from previous versions, but still I see performance issues and I want to make sure with you that I’m using your framework in the right way. I created a sample project that fills a diagram with StepNodes and creates some random connection between them. I made sure virtualization is ON and ran it in different scenarios, each has a different amount of shapes in the diagram. Despite the fact that between one case to another the number of visible shapes is the same - there is a difference in the time it takes for the diagram to show up. In the sample project I’m creating rows of shapes (StepNode), each row contains 100 items. There's a slider at the bottom that determines how many rows will be created. So for example - if the slider is set to 5, 5100 items will be created. If the slider is set to 10 10100 items will be created. Now, take the following scenarios, create 10100 items and then create 15100 items and measure the time is takes for the diagram to be set (ds.Diagram = newlyCreateDiagram): 10100 => 0.29s 15100 => 0.56s 20100 => 1.03s 30100 => 2.17s 40100 => 3.6s 60100 => 8.1s In each of the following executions, the amount of visible shapes/connections is the same as the screen size is the same. STILL, the performance degrades significantly between each case. The expectation from our tool is that it will be able to cope with extremely large amount of items without blinking. Am I doing something wrong? Can you direct me on steps that would improve the performance? A sample project is attached. Gilad |
|
|
|
|
Hi Gilad, Thanks for creating and sending the performance project. I've profiled this and improved the performance of loading the application you sent. You're certainly not doing anything wrong. When I first ran the app, 100 rows of 100 nodes took 22 seconds to load on my machine. After improving the performance, the same diagram takes 1 second to load. This performance improvement will be available in the next nightly build, which you'll be able to download from here in about 11 hours: http://www.mindscapehq.com/products/wpfdiagrams/nightly-builds Note that this performance increase was achieved by implementing simplified base-case ZOrder calculation for basic diagrams. If you end up setting the ZOrder property of nodes or connections in your diagram, or if you set the Parent property of nodes (e.g. to implement node grouping), then the performance improvement will not be available, so let me know if that ends up being the case. Let me know if you have further questions about WPF Diagrams. -Jason Fauchelle |
|
|
|
|
That's SUPER! We don't need the ZOrder or the grouping so it sounds promising! Looking forward to checking it out. I have a few days off, I'll check it out the second I'm back to business. Your effort and fast reply is highly appreciated!! |
|
|
|
|
Hi Jason, I evaluated the fix you had sent me and it is impressing, the difference is huge! I managed to load a diagram containing 10K of items in no time. The next thing that is very important for us before we make a decision is how the Zoom behaves. It is super important for us that it would be as smooth as possible. Even if it takes a bit time for all nodes to show up when you zoom out - it is critical that the UI will not freeze during the process even for a fraction of a second to ensure perfect smoothness. So I ran a small experiment, I created a simple diagram containing 625 (25*25) nodes and played with the zoom (not such a large amount of instances). What i see is that the Zoom works very smoothly between zoom level 1 to 0.5 and between 0.4 to 0 but between 0.5 to 0.4 there's a glitch, the UI freezes for a second or two. That's an issue for us and we will need to find a solution for that before we make a decision whether to go with Mindscape or not. I provided a sample solution and i would appreciate it if you guys can take a look and tell me if I'm doing something wrong or if there's something else i can do to make it better. BTW: I did not introduce myself, I'm a SW architect at Intel, the tool that we're developing the main tool in our department with lots of internal users, lots of visibility and focus. So those small details matter to us very much. (I accidentally attached the wrong sample project, please refer to the latest between them, I couldn't understand how to delete the old one). Thanks in advance, A fast response will be highly appreciated! please use latest sample, I uploaded one with a mistake and couldn't delete the others **otherwise, just ensure both 'i' and 'j' run each from 0 to 25 in the loop of the MainWindow code behind. Gilad |
|
|
|
|
Hi Gilad, Great to hear the performance of my previous improvement is working well for you. Thanks for sending another repro. Sorry for the attachment confusion - we don't currently have a way to delete them while writing a post. As you may have guessed, the performance lag when zooming between 0.5 and 0.4 is caused by the node template switching. When zooming past 0.4, a simplified template is applied to the nodes that doesn't display the content. This makes it much faster to render a larger number of nodes when zoomed far out, but this does not offer a good zooming experience as the template switching operation is slow - perhaps this will be reverted in the next version. Note that this only occurs for nodes that extend ShapeNode (Which StepNode does). If you modify your repro project to populate DescisionNode instances, you'll find that the zooming is smooth all the way. After doing so, you may also want to add more nodes to see how zooming performs in a heavier diagram. Depending on how complex your project is, you may find that you'll be implementing your own Nodes and providing your own styles for them. In that case, there won't be any template switching unless you implement it into your styles. If you do end up requiring ShapeNode, then let me know and I'll be able to add an option to disable the template switching. On the topic of custom diagrams, I'd recommend taking a look at the ActivityDiagram sample included with WPF Diagrams - it's a good example of creating custom nodes and styles. I hope this solution works well for you. Let me know how it goes. -Jason Fauchelle |
|
|
|
|
Hi Jason, I'm going to work with custom nodes so I'll handle it there. Its good to hear though that the problem is because of the node template switching and not something else, now I'll know what to pay attention to. As an improvment suggestion I think it would be reasonable to ensure the new simplified template applies for nodes that are being added to the view port and not ones that already exists in a way that would prevent that freeze. The other nodes can switch template later in a slower pace. This is probably what i'll be implementing with the custom nodes. Anyway, you are super! You're answers are helping a lot. I'll continue to bother you until I manage to get to what i want :-) Gilad |
|
|
|
