Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Layouting Performance #7743

Open
AndrejBunjac opened this issue Mar 3, 2022 · 0 comments
Open

Layouting Performance #7743

AndrejBunjac opened this issue Mar 3, 2022 · 0 comments

Comments

@AndrejBunjac
Copy link
Contributor

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.

image

image

image

Thanks for considering it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants