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

Animations performance #51

Open
kkard2 opened this issue Apr 18, 2024 · 5 comments
Open

Animations performance #51

kkard2 opened this issue Apr 18, 2024 · 5 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@kkard2
Copy link

kkard2 commented Apr 18, 2024

Running the demo in release mode results in a noticeable lag when opening a dialog with animations. It seems to get better after a few opens, probably because of some Avalonia caching.

Is this behavior expected/noticeable on other machines? I don't have the best PC in the world, but I would assume these animations should not be that compute intensive.

I may look into optimizing it in the future, but I'm not very proficient in Avalonia so if someone wants to pick it up go ahead. For now I will opt into dialog without zoom in animation, which mitigates the issue.

@SKProCH
Copy link
Member

SKProCH commented Apr 18, 2024

Yes, this is a known issue, but I can't find the root cause. I will appreciate any help with this.

To disable animations you can use build in property (DisableAnimations or something like this)

@SKProCH SKProCH added bug Something isn't working help wanted Extra attention is needed labels Apr 18, 2024
@LilithSilver
Copy link

Yes, this is a known issue, but I can't find the root cause. I will appreciate any help with this.

I'm not very familiar with Avalonia either, but perhaps I can provide some insight. The reason for this choppy behavior is a large amount of object allocations - hundreds and hundreds per frame, while the animation is going.

It looks like the biggest contributor is many List<T> being allocated, followed by AvaloniaPropertyChangedEventArgs<T> of various types. But overall something about the animation architecture is allocating way more than it should (ideally, 0 allocations).

I don't know if the issue is with Avalonia's animation system or the way it's used in DialogHost.

You can debug the allocations with Visual Studio, if you have it: use the .NET Object Allocation tracking tool in Debug->Performance Profiler. Note how the allocations decrease with further opens of the dialog box, and it looks like List<T> stops being allocated. As such, the animation gets less choppy, but it doesn't get fixed entirely (since there's lots of allocations still).

@SKProCH
Copy link
Member

SKProCH commented May 11, 2024

This info actually gives no clue about true reason for that.

I've also tried to use composition animation for that, and there is the same laggy behavior, so, probably the problem is something else (not on the animation side).

@LilithSilver
Copy link

Perhaps a stripped-down repro of the animation could be created? It's possible the issue is on Avalonia's end, what with all the observer-related allocations going on. If a small repro could be created, the issue could be brought up over there.

@SKProCH
Copy link
Member

SKProCH commented May 11, 2024

I've already think about it. But DialogHost is actually quite complex behavior under the hood. I've already tried to extract some parts in the past, but no luck. Probably I've should try to do it again, but currently I've doesn't have plenty of time for it. If someone want to do - it will be nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants