Application render framerates seem to depend on element spacing within a panel

[mw1920]

I am writing an Avalonia app that needs to render bitmap-based animations and custom draw operations at a faster frame rate, typically 30-60 FPS. I have noticed that the final frame rates delivered don't necessarily correlate with just the number of running animations, but also with the amount of space around the elements. I have attached a sample to demonstrate this (which only includes a bitmap based widget). On my reasonably fast machine at standard HD resolution, the frame rate is what I expect, but at 4K and full screen, the frame rate drops, but can be restored by resizing the window to eliminate the space around the animations. The problem gets significantly worse on lower power hardware (e.g. RPi 4) where the frame rate varies from expected to very slow as the window is resized larger.
I cannot easily explain why this is the case with my limited knowledge of Avalonia, so I am presenting the problem here in the hope that someone could throw light on this, or perhaps tell me raise an issue.

AvaloniaTestApp.zip

[timunie]

A 4K screen is huge task for a low end device. The number of pixels is square, so double screen size means 4 times more pixels to calculate.

[mw1920]

Yes, I understand. I didn't try at 4K on RPi 4, only HD - should have made this clearer. RPi 4 is fine and sees 60FPS when there's no intervening space between the animation controls, but slows down considerably as the window is sized larger and more and more of the Panel that contains them is invalidated. It looks like the achievable frame rate is proportional to the actual size of the Window, as well as the number of the animations being run? The point I'm trying to make is what I'm seeing is just what happens as the render code has to deal with more pixels? i.e. there's no bug here?

[timunie]

I haven't checked your sample. Also I have no Raspberry to try, so can't finally answer. I can however suggest to take a look into src/samples/RenderDemo and ControlCatalog (animations page)

[mw1920]

I'll do some more tests with the samples you mentioned and I will see whether they behave differently.

[kekekeks]

Avalonia attempts to only draw the changed area of the screen. However it only tracks ONE area per frame. When you have two changed elements at the opposite corners of the screen it will trigger a full repaint.

We used to have accurate dirty rect tracking, but it involved its own problem with repainting complex backgrounds shared by multiple elements.

Verify that you are using GPU-powered rendering, it should help with the frame rate.

[mw1920]

That does make sense now and correlates with what I see in frame rate.
I guess that if I need to get around this, then I would need to have my animating visuals done another way, such as within a NativeControlHost instance, which I think would not be affected by the rest of the window contents in the same way as a regular Visual?

I double-checked for GPU rendering being used. It's being used on both Windows and RPi 4 platform.

As a side point, I found that the best FPS performance on both Windows and Linux for this particular application was to use the non-default renderer settings, namely Win32RenderingMode.Wgl and X11RenderingMode.Egl (but the FPS is still not enough for my needs).

[maxkatz6]

WGL on windows would limit you with 60 fps max IIRC. Because composition renderer won't be used.

[mw1920]

WGL on windows would limit you with 60 fps max IIRC. Because composition renderer won't be used.

Interesting, I was under the impression that the rendering is limited by the render loop timer to 60 fps in all cases. So Angle has a higher tick rate, or a way of rendering something outside the render loop?

[kekekeks]

We are using DWM-based timer when rendering goes through DWM composition APIs. Otherwise fallback timer is used.

[mw1920]

OK many thanks for explaining.