Animations performance

[kkard2]

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]

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)

[LilithSilver]

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]

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]

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]

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.

[bearyung]

I've found that even I've set the "DisableOpeningAnimation" property to True, the content itself has disabled the animation, but the fade in effect of the background (from transparent to the OverlayBackground I've set) still has fade in animation, is it possible for me to disable that fade in animation effect of the OverlayBackground?

Thanks.

[SKProCH]

Should probably handled by pasting this style in your app:

<Style Selector="DialogHost /template/ Rectangle#PART_ContentCover:not(.notransitions)">
  <Setter Property="Transitions">
    <Transitions />
  </Setter>
</Style>

[bearyung]

Should probably handled by pasting this style in your app:

<Style Selector="DialogHost /template/ Rectangle#PART_ContentCover:not(.notransitions)">
  <Setter Property="Transitions">
    <Transitions />
  </Setter>
</Style>

I've tried but failed, my dialogHostAvalonia:DialogHost/ is in MainView.axaml and I've added the above style under <UserControl.Styles/> but the 0.3 seconds LinearEasing still happens.

I've created a repo to reproduce this, as follows:
https://github.com/bearyung/DialogHostDemo

[SKProCH]

Yeah, this is not properly overrided. I've should make changed in the package itself.

[Ruuno]

Is the only option reduce the visual lag by disabling the opening animation and also using the "disable-content-cover-animations" or are there any new findings about solving the performance issue alltogether since they are nice to have?

Thanks for your work.