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, I'd created a sample project that looks quite similar to what we have here. By using the sample project I would like to highlight several performance issues that are hitting us: 1. Creating 100 nodes, turning ON complex styles, will cause serious performance reduction when we're trying to Zoom / Pan. This is our main concern, because our customer might easily creating over 300 nodes in 1 diagram. 2. The difference between having "Snap Line Drawings" on the diagram is a huge difference in rendering performance. 3. Switching between Styles for the nodes will cause the memory to keep going up eventhough we're reusing them? (Possible memory leak?) This might be a concern if memory keep going up when we creating new instances of Diagram. Our application aims to create multiple diagrams at times so that the user can work on multiple 'documents' without the need to 'reload' the nodes. *4. Side question, I always get this error: {"Cannot find resource named 'CursorActionTypeConverter'. Resource names are case sensitive."} when trying to use "NodeStyleSelector", this doesn't happen on my real project, only on this sample project, though the codes are the mostly the same, any idea why? We hope that you can help us in tackling the issues, advice us on the best implementation that needed in the Diagram Control to avoid performance impacts. Thanks. |
|
|
Hello Overall the sample that you sent us works well at our end. I don't think I'm seeing the bad performance that you mentioned except when there are lots of nodes on the screen at once. Zooming and panning are very simple operations. They do not have any complicated loops or calculations and so most of the performance hits for these operations will be comming from WPFs ability to render to the screen. 1. To help improve the performance of this, you could try simplify the styles/templates. Even for the complex styles, you may be able to simplify the templates without changing the appearance of the nodes. Look through all your styles and templates and try to strip out as much unneeded stuff as you can. Look for things like grids, borders, rectangles and other visual elements that are redundant or aren't needed in the style. Try to refactor the xaml in some places to reduce the number of visual elements as much as possible. The nodes in your sample all have resizers around them. But resizing the nodes seems to simply crop the rectangle. If you don't need nodes to be resized, then you can remove the resizers entirely which will help reduce the visual element count. If you are seeing relativly good performance when zoomed in (only a few nodes fit on the screen), but worse performance when zoomed out (many nodes on the screen), then you could try create 2 or more templates for each node. Each template can have a different amount of detail on them and can be used at different zoom levels. So when zoomed in, you use the templates that you're already using. But when zoomed out to half way, your nodes could use a much simpler template with less details. For example, if you are zoomed out quite far, things like the text and borders are difficult to see. So when zoomed out, you can use a template that uses less visual elements. If after using all these techniques the performance is still bad, then you may just need to simplify the appearance of the complex styles. 2. I've noticed this too. Again this is mostly critical when zoomed out quite far causing many lines to be rendered on the screen. This can't be helped. When zoomed out to a certain level, you could either remove the snapline drawing, or use a different snapline drawing that renders less lines. 3. This is probably a memory leak at our end. I'll try look into this. 4. I'm not sure why you're encountering this error and havn't reproduced it. You may be missing a reference in the sample somewhere. This issue is not present in WPF Diagrams 2.0 It looks like you are using WPF Diagram 1.0. Version 2.0 includes a lot of performance enhancements and memory leak fixes so you may want to check it out. The zooming and panning operations will still be the same though so you'll still need to look into the techniques I suggested. Let me know if you need more help. |
|
|
Hi Jason, Thanks for your prompt reply, appreciate your advice on those items. 1. I'll continue to look into the possible optimization of styles in this case. Since you can't really feel the rendering performance impact here, I guess that might related to per machine capability of rendering the UI. Anyway, the suggestion of splitting into different templates and switching them upon different zoom level would be a great idea. Will probably go into this route. 2. Yea, this is an issue when user zoom all the way out and do panning on the diagram with a lot of nodes. We do hope there is something can be done to optimize the rendering of snapline drawings, since the snaplines are done according to user request. 4. Try to uncomment my code in the Diagram control xaml code, at the end of the resources area. NodeStyleSelector="{StaticResource DefaultTypeStyleSelector}". If after un-comment you still can't see the issues, then I'll try to refactor and see what's the root cause. * A little request here regarding the Diagram 2.0, would it be possible for you to help me migrate the current sample project to use Diagram 2.0? I found that there are some major changes in 2.0 that causes most of my codes won't work in this sample. Especially the node style, it would be helpful if you can make it so that the migration on our side would be easier since we can refer to this sample project. Thanks. |
|
|
Hello We can help you migrate to Diagrams 2.0 by answering any forum questions you have about it and giving advice. Start by looking through the samples to see how to create custom nodes and styles. And maybe make a few simple samples to try this out. Make sure you keep a backup of your current projects, then switch to using the Diagrams 2.0 dlls. Then convert the projects a little bit at a time. You may want to create some standalone projects to get individual parts of it working again. For the styling, the connection-template-selector, node-template-selector, and calculator-selector no longer exist. All you need is the node-style-selector and connection-style-selector. You can use setters on the styles to set any of the properties you need. For nodes, you can set the NodeTemplate property to provide the shape and color of the node. This is basically what you would normally use in the template selector. Instead of the calculator selector, you can set the ConnectionPointPositions property using a setter on the appropriate node styles. (Unless you are setting up calculators in code). - Jason |
|