You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Hi, I am implementing a relatively complex set of views using a custom implementation of Avalonia (some of the locator interfaces are replaced by custom impls). The views rely heavily on data templates because they will be generated differently depending on the types found in the list etc. The view is working perfectly fine but I was experiencing some performance spikes when opening such views so I investigated where the bottleneck is happening.
It seems that most of this spikey behaviour comes from the layout pass. I performed some measurements with dotTrace in your control Catalog in debug mode and here are some examples of dot trace output:
(simple control) - switching to acrylic tab - layout pass is 79ms
(simple control) - switching to autocompletebox tab - layout pass is 145 ms
(extreme control) - switching to datagrid tab - layout pass is 554 ms
My views have enough bindings that make them more comparable to the datagrid (the layout takes about ~230 ms and since in my case Avalonia is a layer in a bigger app - this micro-freeze of the UI thread is a very undesirable feature.
Describe the solution you'd like
As I understand that layouting will always be the heaviest performance bottleneck I suggest reconsidering the method in which the layouting is done so that it becomes thread-safe and can be run in async. As I understand - this happens because layouting heavily depends on values provided by bindings so maybe they can be snapshotted in some way before the layout pass starts?
Describe alternatives you've considered
I tried making screens that rely less on bindings and are therefore less costly in performance but this limits me from using some of the most powerful features of Avalonia so I don't think this is a viable pathway for me.
Thanks for considering it!
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Hi, I am implementing a relatively complex set of views using a custom implementation of Avalonia (some of the locator interfaces are replaced by custom impls). The views rely heavily on data templates because they will be generated differently depending on the types found in the list etc. The view is working perfectly fine but I was experiencing some performance spikes when opening such views so I investigated where the bottleneck is happening.
It seems that most of this spikey behaviour comes from the layout pass. I performed some measurements with dotTrace in your control Catalog in debug mode and here are some examples of dot trace output:
(simple control) - switching to acrylic tab - layout pass is 79ms
(simple control) - switching to autocompletebox tab - layout pass is 145 ms
(extreme control) - switching to datagrid tab - layout pass is 554 ms
My views have enough bindings that make them more comparable to the datagrid (the layout takes about ~230 ms and since in my case Avalonia is a layer in a bigger app - this micro-freeze of the UI thread is a very undesirable feature.
Describe the solution you'd like
As I understand that layouting will always be the heaviest performance bottleneck I suggest reconsidering the method in which the layouting is done so that it becomes thread-safe and can be run in async. As I understand - this happens because layouting heavily depends on values provided by bindings so maybe they can be snapshotted in some way before the layout pass starts?
Describe alternatives you've considered
I tried making screens that rely less on bindings and are therefore less costly in performance but this limits me from using some of the most powerful features of Avalonia so I don't think this is a viable pathway for me.
Thanks for considering it!
The text was updated successfully, but these errors were encountered: