Problem with hidden nodes while exporting to png

Hello,

after update from 2 to 4 version I have some problems with exporting diagram to png. When I use DiagramBitmapRenderer to export, I receive file with all nodes and connections on diagram (including hidden - hidden nodes and connections have set Visibility property on DiagramNodeElement object to Hidden or Collapsed). In version 2 everything was ok. It's a bug or maybe I'm doing something wrong?

Thanks for help.

Hi Bater,

Have a go at setting the IsVirtualizing property on the DiagramSurface to false and see if that solves the visibility issue in the exported images. This will bypass a performance improvement, so the performance of initially visualizing the diagram will be roughly the same as what you got in version 2, let me know if that's a problem.

-Jason Fauchelle

Unfortunately, I've already set this property to false.

Hi Bater,

Sorry, I have not been able to reproduce this issue. Please send a simple repro project and I'll look into it further for you.

-Jason Fauchelle

Ok, so I made project based on yours QuickStart sample project. At the beginning you have two nodes (start and end) and connection between them. Then after clicking on the "Hide" button, start node and connection are hidden. Now, when I click "Export PNG" all diagram nodes and connections (even hidden) are exported to png file. I'll be appreciate for any suggestion how I can fix that.

Hi Bater,

Thanks for the repro project, I was able to reproduce the issue now.

The best way I've found to fix this is by adding an IsVisible property to the DiagramNode and DiagramConnection model classes. This property will be in the next nightly build which will be available at around 1200GMT from your account downloads page. From now on, you'll need to use the IsVisible property on the node or connection models to hide them, rather than setting the Visibility on the visual elements. The generic styles will use the IsVisible property to hide the elements for you. This approach also means the IsVirtualizing property doesn't affect whether or not this works.

-Jason Fauchelle

Sorry that I’m so late in answering, but I was very busy in last days. Of course your fix works perfectly. Thanks for your help.

All good, great to hear the solution worked well for you!

-Jason Fauchelle

I have one more question. You wrote when I set IsVirtualizing property to false, the performance will be roughly the same as in version 2, but it isn't. In fact is much worse. I don't expected performance improvement taking into consider that I disabled Virtualizing, but I don't expected decrease of efficiency too. For example diagram with 50 nodes now is generating 3 times longer than in version 2. Is it normal that now it takes as much time? Setting the CanCalculateConnectionIntersections property on false also don't help enough. I can't enable Virtualizing, because logic set ContextMenu and register some events for DiagramNodeElements when diagram is loading and I have problem with null references, probably by not existing some nodes in viewport.

Hi Bater,

If you send me a simple repro project, I could have a look at what's going on. Better yet though, I would recommend that you have a go at refactoring your logic to allow the virtualizing feature to be enabled.

Regards -Jason Fauchelle

Please see the repro project attached. It generates 100 nodes and about 2500 connections. It is not exact scenario we have, but it shows the difference. Using version 2 it takes about 130ms to generate diagram. When you switch to version 4 it takes about 300ms (on the same machine). Our real scenario is a bit different as we have much more nodes and not as many connections. But it should be enough to reproduce the performance issue. Thanks for the suggestion to redesign the solution to use virtualization. We know that it is an option. But it is a lot of effort on our side to redesign the whole solution we have. As we want to buy and migrate to version 4 just to be up to date, redesigning everything is not worth the effort. We will rather stay with version 2 instead.

Please have a look at the attached project and try to verify what is going on. If you could preserve the performance of version 2, it would be great for us (and probably for the product to ;))

Best regards

Hi Bater,

Thanks for sending through that repro project. I couldn't find anything obvious that we'd be able to improve performance wise while virtualization is disabled. I'm sorry to say that the options are to stick with version 2, or get it working with virtualization. The main additions to version 3/4 is virtualization and diagram model classes that make it easier to implement custom diagrams.

-Jason Fauchelle

I'm sorry to bother you, but I made one more test which is much more suitable to our scenario. I attached it as repro project to this post. It again generates 100 nodes but now first node is connected to second and each next (without last) is connected to previous, next and 2 random. Using version 2 it takes an average 205ms to generate diagram, but when you switch to version 4 it takes an average 630ms although IsVirtualizing property is on and CanCalculateConnectionIntersections is off. Please look at this again and maybe you find some solution, because this repro project shows that your second suggestion (get it working with virtualization) is also slower than our current performance (version 2).

Best regards

No worries Bater,

Thanks for the additional repro project.

There are a couple of things that I need to point out first. The virtualization feature affects the performance of rendering the visual elements of the diagram. The idea is to only render the objects that are within the current viewport. If a diagram has 1000 nodes, but only 20 are displayed in the viewport, version 2 - with no virtualization - would render all 1000 objects meaning the diagram would take some time before it is presented to the user, and the application would be unresponsive while loading all the visual elements.

The virtualization introduced in version 3 means that in that same diagram, would only load the visuals for the 20 nodes in the viewport, and hence the diagram can be displayed to the user almost instantly. You latest repro project uses the SizeToFit mode which causes all nodes to be displayed, meaning virtualization doesn't help.

If you boost the number of nodes and connections generated in your repro project to many hundereds, and then remove the SizeToFit mode, you should see a clear difference between version 2 and version 4 when presenting the diagram. This is the benefit of virtualization.

Since the rendering is done on a different thread, your stopwatch is only measuring the time it takes to load the diagram model, not the visual. I was still expecting version 4 to have a better time here, due to version 2 building more UI elements in preparation for rendering. Version 4 does have an overhead of populating a specialized data collection that provides a quick way to answer "what nodes are currently within the viewport" as required by virtualization. Populating the specialized collection is slowest when adding nodes near the edge of the diagram as it needs to update the bounds of the diagram. The long nature of your test diagram means every node added is hitting this slower case. A more square arrangement of nodes may have better performance, but shouldn't be by much.

That said, version 2 ran at around 200ms, and version 4 ran at 230ms for me which is not as significantly different as your results. I'm not sure why that is.

One solution that you may be able to use is to implement data-virtualization. Similar to ui-virtualization, the idea is to only load model objects within or close to the viewport. Doing this for a diagram structure is not so easy though. If the ui-virtualization I described above is not helpful to you, then version 2 will work better for you performance-wise.

Sorry this is not the reply you were hoping for, but I hope that helps explain the situation.

-Jason Fauchelle

Thanks for explanation, but it's quite strange that the difference is so small in your tests. Could you send the project in the same state as you test it? Because 30ms is acceptable for us and maybe we attach dlls or do something incorrectly.

Hi Bater,

Attached is your project in the state that I was testing it. I ran it again and still get a very small difference between version 2 and 4.

There isn't much difference to it than how you sent it to me. I used the dlls you provided and simply add them as references. I have changed the model to add 600 nodes and 2396 connections. I had also changed the Zoom mode back to default. Feel free to change that back to SizeToFit but remember my previous notes about this defeating the purpose of virtualization.

Remember the timing value in the result file only captures the time to build the model. When you observe running the app with the different versions however, you should see that version 4 displays the diagram to you much faster than version 2 which should have more of a noticeable lag while the app is starting up. (That is with the default Zoom mode).

Let me know how that goes.

-Jason Fauchelle