Dynamic updates on Nodes about blazor.diagrams HOT 4 CLOSED

Hi @KameshRajandran,

1. Create 10000 nodes initially.

This is a very large number of nodes. The library tries to make large numbers of nodes possible by virtualization, but whether that's sufficient depends on usage. If all nodes are simulatenously visible, the library can't help you. You might be better off drawing such large diagrams as a canvas, e.g. with Excubo.Blazor.Canvas.

2. Add 10 nodes dynamically.

The documentation shows you how you can let the user add nodes. Have a look at the demo and corresponding source file.

3. How to update the fill colors for selected shapes?

The Fill and Stroke parameters of a node can be used to customize style. If style needs to change on selection, you can do that by listening to the SelectionChanged event and processing selected nodes. You are also free to design your own custom nodes, which then can behave any way you'd like on select. Sample code can be found here.

BR
Stefan

from blazor.diagrams.

#Hi Stefan,

We have tried with 1000 nodes in your Performance sample. It's getting very slow while dragging a node.
Already we have tried this sample in the server-side application and hosted that application with 1000 nodes, the performance of interaction is very low. If we render the sample locally, the performance of interaction was ok, but when we host in remote machine(hosted in other regions) it seems the performance was too slow. Is this a maximum performance for blazor in server application?

Here we have attached video link for performance issue in your sample after rendering around 1000 nodes.

Excubo.Blazor.Diagrams demo (Blazor ServerSide) - Google Chrome 2020-08-14 16-07-14.zip

Regards,
Naganathan K G

from blazor.diagrams.

Hi @Naganathan,

the issue is fundamental to Blazor: many times an application renders, it's actually not necessary. Avoiding it is not always straight-forward. In this particular instance, the issue is with bind-X on the nodes. The bind causes a re-render of the entire component that contains the diagram, which of course includes the diagram. Since the diagram contains a large number of nodes, the delay of rendering even though nothing changed on that large number of nodes becomes noticable. This issue is tracked in Blazor here: dotnet/aspnetcore#18919. Sadly it doesn't seem to get enough attention.

In this particular case, I think I was able to work around the issue. Please update to version 1.6.6 and please let us know whether this performs better in your scenario.

BR
Stefan

from blazor.diagrams.

Closed due to no activity for several months

from blazor.diagrams.