Performance issues on Raspberry Pi on X11 when navigating and using animations

[HakanL]

I've been trying to get to the bottom of an issue I'm facing with my application. It runs on a RPi 4, ARM64 on X11 and .NET9. The issue is when I navigate between pages in my application (using the Uno Navigator) I get very slow rendering on the page I'm navigating to, I can see parts of the screen being painted, the title, cards, icons, staggered. The strange thing is if I trigger the navigation externally (my device has a hardware button), instead of touching the screen, then it's butter smooth, no staggering effect. I have narrowed it down to the UI thread being congested when navigating and I believe it's because of the animations that are triggered when touching cards (Tapped event on cards in a ListView), but it also happens when I use a regular button so I don't think it's directly related to the card, or ListView.
If I remove animations (by overriding the style, which is a pain), then I don't have this issue, so a workaround is of course to just not use animations, they aren't that useful anyway when using a small touch screen device as your finger is often covering the button where the animation is played. But I wanted to report this, or see if this is expected, or if there's perhaps an issue. I can't easily go back to an earlier version of Uno in my application now, but I feel like this wasn't an issue in previous Uno versions. I also haven't set up a simple application to show this yet.

Could there be an issue where perhaps the animations aren't stopped when navigating away from a page (actually my page is the same, it's just the ViewModel that is changed = DataContext changed)? If I enable logging of animations then I can see the animations keep running even after my DataContext has been changed, and even if the animations may not be visible (since the VM is changed with new menu options), they seem to eat up resources in the UI thread so the rendering of the new page are very slow (takes up towards 1000mS instead of around 200mS when using my hardware button/no animations) and the user experience isn't as nice.
AnimationLog.txt

In the attached logs I'll point out some important timestamps:
21:37:15.771 VRB [MenuPage@11] Tap on card Cues - This is logged in the Card_Tapped event, which will schedule an action on the UI thread using SynchronizationContext (IScheduler)

21:37:15.835 VRB [MenuFocusManager@11] Short press on item ListViewItem. Ctx.Count = 1, id Cues - This is executed on the UI thread, as you can see it took 64 ms just to get to this, when I trigger via external button this is < 1mS.

21:37:15.932 VRB [MenuPage@11] Data context assigned = MenuViewModel - This is the OnDataContextChanged on the Page when the new ViewModel is assigned. It's at this point I would expect any animations from the previous visual tree to be stopped, but as you can see in the log lines right after they keep running (although they report failures, but I assume they still clog up the UI thread)

21:37:16.352 DBG [MenuFocusManager@11] Navigation took 517 ms - At this point the new page is displayed, this is triggered via the RouteChanged event. In this particular log it only took 517 mS, but it should've been around 200 mS, and the rendering of the new page is still staggered (and the storyboard animations keep going for a little bit longer).

If I add a 2 second delay in triggering the navigation after the tap event then I don't have this issue, the animations are completed, then the navigation happens and there's no staggered rendering and it's all fast and smooth (just like hitting the hardware button).

I also don't know if there's a way to "force" a higher priority to the rendering of/navigating to the new page over animations? Since it all has to happen on the UI thread it seems that congestion can happen, however I don't know if there are multiple events fired, or if there are a few longer running events that clogs it. On a fast Windows machine you don't notice this, but on a slower Raspberry Pi it becomes obvious.

[jeromelaban]

Thanks for the report. At this time, animations are still run on the UI thread, and there's no available workaround to change this prioritization.

One thing that you could try though, is to reduce the frame rate which is a 60 by default. This may be too high for a low powered device. In your program.cs, set the first line FeatureConfiguration.CompositionTarget.FrameRate = 15;, or which ever framerate makes sense for the device.

[jeromelaban]

Thanks for the update. The framerate counter is specific to animations, but if there's something that queues on the dispatcher in an uninterrupted way (a continuous dispatch loop) this can move the render loop to a higher frame rate.

Is this particular framerate present always in your app? Does it show in specific scenarios or interactions (e.g. touch)?

/cc @ramezgerges for visibility.

[HakanL]

I see, this reported framerate is quite odd, it only happens when I open a Flyout (via mouse click). I've tried to reproduce it in a sample app, no luck yet, will report if I can narrow it down, it may still be something in my application (but I haven't been able to isolate it).

[HakanL]

Jerome, I was able to reproduce the issue with the runaway FPS. It happens when I display a Flyout AND using the hack to display the expanded scrollbar (#14474) without a mouse. I have verified that it's not the GoToState part that is called repeatedly, instead something in Uno is queuing dispatch items repeatedly when the scrollbar is expanded (which is odd, but I just happened to stumble upon this).
Repo is here: https://github.com/HakanL/FastFPSUpdateIssue
In the repo just click the Flyout button and the FPS should max out. If the scrollbar isn't visible (not enough items in the list), even with the "hack", then the FPS is normal. You can test by changing the Height of the ScrollViewer to 200.

[jeromelaban]

Thanks for the repro! Let's track in #20634

[HakanL]

I can confirm this is fixed in Uno.Sdk 6.1.0-dev.207.