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
|
We are experiencing slowness (GUI freezes) when we change the Z order of multiple connections, say for example if we give a higher value to 20 connections it take nearly 3 seconds for the diagram to process it, meanwhile the diagram is completely frozen. The diagram contains 1000 instances but only around 100 connections. The view port contains around 30 instances and 10s of connections. Can you please shed some light on this? Our requirements says that when the user select nodes all connections going out of the selected nodes should come to the front, but it seems to put a lot of stress on the diagram. I've put a breakpoint in the PathBuilder (we use custom one) and it doesn't even get there. So if it doesn't redraw the connections what is taking so long for the diagram to process it? I know you normally ask for a sample project - but can you please check it out first before cause it is will take us a significant amount of time to create one. We downloaded your source code and we are trying to debug you code ourselves to understand why this is happening, this is super important for us. We don't understand why it needs to take so much time. Something is definitely being done in an inefficient way. We took a close look at your code and we found the code that has the performance issues - you even had a comment acknowledging the performance issues (see image attached to this post). Since this is super important to us - we will appreciate if you can provide either a fix or a workaround. We are going to try and make changes to the code - but we prefer the fix is provided by you so we can still get updates. Thanx, Gili |
|
|
Hi Gili, Apologies for the trouble here. Admittedly, the ZOrder system of WPF Diagrams is certainly the slowest part of the whole product, and could be implemented a lot better too. I've been able to use one of my older performance test projects to reproduce this issue. My project has close to the number of nodes and connections that you've mentioned, and changing the ZOrder of a connection can take 3-6 seconds. As you've discovered the slowness is caused by sorting the entire collection of model diagram items when the ZOrder changes. I've now changed this to use an existing specialized binary search to first find the index of the item that changed in the ZOrdered collection and then remove the item at that index. Then I use another existing specialized binary search to find the ideal insertion index and put the item back in. This change causes my repro project to perform the same operation instantly. This improvement will be available for you to try out in the next nightly build. Please note that for now, this performance improvement has only been applied to connections, not nodes. The case of nodes is a bit more complex due to supporting grouping/nesting. The position of a parent node within the ZOrdered collection can affect the position of other nodes and connections in various ways - hence why it's easier to re-sort the collection in this case. I hope this improvement solves the GUI freezes in your application. Please let me know if there are any issues. -Jason Fauchelle |
|
|
Thank you so much! I will give it a try once the nightly build is available. About the nodes. So we need to ability to bring a node up to the front and send some to the back as well. I was so overwhelmed from the connections that I didn't even try the isolate the affect caused by the nodes. So what I don't understand is why you are not handling only the nodes that are within the viewport when you consider the z order. That by itself could improve the performance by a few factors. I will check out today how much the nodes reordering contributes to the degradation in performance and will let you know if we need your help here.We don't use node grouping so maybe you can introduce something that takes this into consideration and simplifies the algorithm. Either way we must provide top class performance to our customers. We cannot compromise in any way. This is the main tool in our department at Intel and the expectations are super high. So if you don't provide us with a solution we will have to make the changes on your source code. If that would be the case, will we experience any license related difficulties compiling and using the code? Thank for the swift response and I hope we won't experience any node related slowness. I will reply back to this post once I conclude the experiment. Thank, Gili |
|
|
Hi Gili, In terms of updating the actual visual elements as to what order they get rendered in, only the elements within the viewport are updated. The model on the other hand keeps a z-ordered collection of all model items which makes it easier to write unit tests and perform operations related to z-order. When the z-order of items change, the collection needs to be kept up to date. That said, the way we've implemented it could probably be better. Maybe there doesn't need to be a collection, maybe there could be a better way to query the exact order of any arbitrary model item. Or maybe there could be some way of marking the z-order of parts of the diagram as dirty. That could make z-order updates truly only consider items (model and visual) in the viewport. To solve your performance issue right now though, the change that I've made is the easiest/fastest I can do. If you've also got node performance issues, we should be able to provide a quick and easy fix like what I've done with connections. The fact that you're not using node grouping will certainly be a huge help. If you ever do need to update our code, you won't have any licensing issues when building, but as you briefly mentioned previously, it will be a lot more difficult to continue getting updates. If on the off chance that it did come down to you needing to update our code, we could always have a look at including your changes in the product - of course, as long as they are not specific to your application, won't cause breaking changes and won't take long for us to add. I look forward to hearing how the next nightly build goes for you. -Jason Fauchelle |
|
|
Hi Jason, first - thank you again for the quick response. This is highly appreciated. When I've made the decision to go with you guys your quick response was one of the main factors. You guys are not disappointing. So I've spent the time evaluating the performance of the node Z re-ordering, I'm experiencing a delay (though less severe compared to the connections) but still very much noticeable. Our specs require us to bring a node to the front when it is being dragged such that other nodes don't overlap it, also all selected nodes should always come to the front. With a node drag i'm noticing a tiny delay when i grab a node and drag it, it is not severe but it disrupts the smoothness of the drag and thus it is an issue for us, again - we promised our customers an out of space experience. Also, the problems gets worse when we try to bring selected nodes into the front, as user can marquee select multiple instances - it deteriorates very quickly. For example when the user does the marquee select on 10-15 instances the marquee rectangle freezes before it is released, this is of course cause we are increasing the Z order of the nodes. You wrote before that you can apply on the nodes the same technique you've used on the connections and that you expect a significant improvement as long as we're not using node grouping. I would really appreciate if you can do it for us. I would hate it if I'll end up changing your code. I'd like to stay in sync with your latest code. If both can be available in the next nightly build it would be perfect but if we have to wait another day for the nodes fix it won't be a tragedy :-) Thanx, Gili |
|
|
Hi Gili, Sorry, missed this yesterday, but you'll be pleased to know that I've now improved the performance of changing the z-order of nodes in a diagram that doesn't use grouping. Just to clarify, that means none of the nodes should have their Parent property set. I updated my repro project to bring selected nodes to the front which had a 1 second lag even in the most basic case. After the improvement, this operation is now instant. This works well in the use case that you've described - around 30 nodes in the viewport of a diagram that has 1000 nodes and 100 connections. (Connection count won't matter much here). Things start to slow down when there are 4000 nodes in the diagram, 300 nodes in the viewport and you try selecting 20 nodes at the exact same time - but even then, it's still less than a second lag. Selecting 100 nodes at the same time when there are 2000 nodes in the viewport is not recommended though. This improvement will be available in the next nightly build. Let me know how it goes. -Jason Fauchelle |
|
|
Thank you so much!! I will give it a try when it gets available and will let you know. I've also been experimenting my own custom implementation for this using Panel.SetZIndex only for the diagram elements that are in view and I am able to get to a very high performance as well. So I'll compare the two once the nightly is available and decide which one I want to use. Thanx Jason, this is highly appreciated. |
|