Low performance compared to WPF

[DrDryg]

Is your feature request related to a problem? Please describe.

When using many objects, Avalonia becomes surprisingly slow. I want to have a node editor that can manage graphs with hundreds of nodes. I have looked into Nodify where there are both WPF and Avalona versions of it. With WPF the application is fast for several 100 nodes with many connections while the frame-rate of the Avalonia implementation start to drop already at 100 nodes. (I have seen this drop in performance in other contexts too with Avalonia.)

Describe the solution you'd like

That the performance of Avalonia matches that of WPF.

Describe alternatives you've considered

There are alternative solutions to my specific problem. For instance implementing various trick to reduce the amount of redraw needed. Though it might solve my issue with a bit of work it would not improve Avalonia and not benifit any other user of Avalonia. So if it is possible to improve the render speed (or amount of rendering needed) in Avalonia it would benefit many more than me.

Additional context

WPF version of Nodify: https://github.com/miroiu/nodify
Avalonia port of Nodify: https://github.com/BAndysc/nodify-avalonia

I have had a discussion with the author (BAndysc) of the Avalonia port that you may find here: BAndysc/nodify-avalonia#10

There you can find some more details including some thoughts by BAndysc on what can be improved in Avalonia.

[kekekeks]

Have you tried with recent nightly builds? Especially after #15110 got merged

[BAndysc]

I used JetBrains profiler and It looks like the performance is mainly limited by rendering in skia:

[DrDryg]

I upgraded to the latest prebuild: 11.2.999-cibuild0048108-alpha
Then I generated 200 nodes and 400 connections and moved around one of the nodes. This cause the framerate to drop down to about 15 fps - about the same as before. In the WPF version of Nodify (playground) it stays at 60 fps.

[DrDryg]

One thing I find odd is the affect by visuals that are not rendered. If I create 1000 nodes and move one of them to the side of the rest and zoom in so that is the only visual object. Then the framerate is at about 30 fps. So visual object not being displayed seem to have an effect. That might be something to look into.

[BAndysc]

This is to be expected, because the panel is not virtualizing, but the same applies to WPF.

[timunie]

@DrDryg either implement your own virtualized canvas or consider to render the items on your own by creating a custom control where you override OnRender.

[maxkatz6]

Should it be converted to a discussion?

[timunie]

done. We can still make an issue from it in case there are good ideas to improve perf. Other than that I can only highlight that we are working constantly on improvements and are even more performant in many cases, but not in all.

[BAndysc]

There is one thing to implement from WPF - Bitmap CacheMode, which is used by original WPF version of Nodify, Nikita mentioned it some time ago, but there is no issue to track it afaik #9319 (comment)

[DrDryg]

Virtualization seem to be the best option for me then, I will have a look what that can give. And I keep my fingers cross that future improvements also will have an impact on this use case. Naively I had expected that elements outside the screen would have close to zero cost, thus making a custom virtualization meaningless. Apparently that is not the case. What calculations are required for each off-screen element that consumes significant time?

[rabbitism]

iirc every element layout change will trigger a panel measure and arrange.

[DrDryg]

So if I move a single node that will trigger measure and arrange on all other nodes? Will that use some cached value for the other nodes or will they have to recalculate based on what elements they contain?

[BAndysc]

In fact, when I was porting the control, I did experiment with virtualization. Unfortunately it is fairly complicated, as even if the node is off screen (which is easy to determine), one still need to know the connector position to correctly determine where the connection should be. I failed to implement efficient virtualization, but looking forward to your ideas. Nevertheless, even with virtualization, we still sometimes need to render everything - when the user zoom out the graph. And we can be pretty sure that's gonna happen with most of the graph use cases. So reducing the render time would be very beneficial anyway

[BAndysc]

Moving a node won't trigger measure/arrange on other nodes. it will trigger measure/arrange on the parent canvas, which will have to call measure and Arrange on all nodes, but it's fast, as the actual position/size won't change. See the performance graph posted above, the layout time is negligible in the current state with slow rendering.

[monkeyK1n9]

I saw this comment here: #12372 (comment)

This might explain the problem. You need to manually increase your memory limit on skia