Improve High-Frequency Rendering by enhancing allocations for GC

[xdi1]

Problem Overview

I'm building a real-time UI (a timeline-based audio editor) in Avalonia 11.3.2 and targeting 60–144 fps animations. However, I'm running into noticeable frame stutter, which profiling shows is due to GC activity caused by small per-frame allocations in Avalonia APIs.

Even with GCSettings.LatencyMode = GCLatencyMode.SustainedLowLatency, the GC still unpredictably collects, leading to visible jitter in UI animations.

Application Context

• Per-frame rendering is done using DrawingContext.DrawText, DrawRect, and DrawLine.
• I've tried both rendering loops:
  • DispatcherTimer.Tick += OnTick
  • A custom Stopwatch loop using Dispatcher.UIThread.Post(...)
• UI controls like Slider, ScrollBar, and TextBlock participate in two-way bindings for timeline state.
• All of the above create per-frame allocations (from formatting, layout, bindings, boxed events, etc).

GC Allocation Hotspots

1. Text rendering via DrawText:

   • Creates SKTextBlob and other objects on every frame.

2. Binding system:

   • Two-way bindings allocate AvaloniaPropertyChangedEventArgs.

3. Dispatcher use:

   • Dispatcher.UIThread.Post or DispatcherTimer allocates per invocation.
   • This is more minimal and can be acceptable.

Request

This issue is intended to highlight a common pattern of allocations for apps requiring per-frame updates. While some of these allocations are minor, they still lead to unpredictable GC behavior and (even Gen0 collections) create noticeable stutters. I understand my use case can be niche but it would be helpful to optimize and add more support for high-framerate app.

Solution

1. DrawText/DrawRect/DrawLine

• Expose methods that takes in required object for rendering like SKTextBlob, so they can be cached in ViewModels.

2. Dispatcher

• Not sure if this is changeable, allocation on this one is minimal though.

3. Two-Way Binding

• Cache an AvaloniaPropertyChangedEventArgs in control and reuse.

Notes

I have also tried using an ICustomDrawOperation with

public void Render(ImmediateDrawingContext context)
{
    var leaseFeature = context.TryGetFeature<ISkiaSharpApiLeaseFeature>();
    if (leaseFeature is not null)
    {
        using var lease = leaseFeature.Lease();
        lease.SkCanvas.DrawText(blob, 0, (float)Position.Y, paint);
    }
}

to replace DrawText, while this does eliminate allocation, I cannot get good result with it. The draw methods in Avalonia.Media give much smoother animation.

[lindexi]

Yes, I also find the Relevant issues. My preformance issues is the Finalize will cost too many time to call the trimed in SharedArrayPool.

[Gillibald]

TextBlock is not caching anything. You need to introduce your own cache that uses Avalonia's text primitives directly. TextLayout, TextFormatter.FormatLine or GlyphRun in combination with the TextShaper.

[nateglasser]

I have run into the same issue. Avalonia's rendering pipeline creates many objects per frame, which leads to noticeable GC hitches. My project mitigates it by using custom draw operations to cache everything possible, but even issuing the draw operation creates a lot of garbage.

For example, here is a profile of 1 second of the "Custom Drawing" tab from the ControlCatalog.NetCore project with just a few ellipses moving around:

Many of these Action allocations are unnecessary. For example, here EglDisplay.Lock is creating multiple unnecessary closures per frame instead of reusing the same Action.

    public IDisposable Lock()
    {
        Monitor.Enter(_lock);
        return Disposable.Create(() => { Monitor.Exit(_lock); });
                             // ^^^^ ideally we would reuse an Action that is instantiated only once
    }

There are many similar examples throughout the compositor, and it starts to add up for real-time animations.

[ZehMatt]

Found this issue after researching the exact same thing, drawing things seems to generate a lot of objects, would be good to have those pooled to avoid GC pressure.

[xdi1]

I've switched to c++ and stopped using Avalonia for a while. There are quite a few fundamental issues in the Avalonia api. For example mouse movement allocates a mouse event object on the heap every frame. These issues make creating a non-stuttering high fps experience impossible (at least I don't know a way to do it). I don't think these problems are hard to fix but you do need to walkthrough Avalonia's source code to fix them. My advice is considering contributing or switching to something else.

[timunie]

If you need high fps, consider to test latest nightly builds and also consider to publish with Native AOT.

[anose001]

@timunie , is Avalonia 12 expected to bring improvements to GC allocations and object creation mentioned here?

[anose001]

@xdi1 , if you don't mind me asking, what c++ framework have you switched towards to resolve the frame stutter problem and has that worked out to the better for you?

[xdi1]

@xdi1 , if you don't mind me asking, what c++ framework have you switched towards to resolve the frame stutter problem and has that worked out to the better for you?

I switched to simply using a low level graphics api (I use DirectX 12, other options are OpenGL, DirectX 11, Vulkan) with c++. There will be more things to implement but it works quite well for me.

Since this is an Avalonia issue we probably shouldn’t go too far off-topic here.

[lindexi]

@xdi1 and @anose001 Could you test the LowLatencyDxgiSwapChain mode in the latest Avalonia version?

Although I didn't optimize your issues (GC), I did try to optimize some of the rendering frequencies. See #20517

[nateglasser]

Just to be clear, the issue isn't performance or frame rate or latency. Those are already quite good! The trouble is specifically the garbage collector causing noticeable animation hitches. Currently, Avalonia's rendering pipeline itself generates a lot of (unnecessary) garbage, and so GC hitches are inevitable.

[anose001]

@lindexi , the UI jank I observe is only on mobile and shows as GC freed events in my logs, so LowLatencyDxgiSwapChain mode would not help here in my case. My desktop machine is quite capable so I cant tell if that is an issue there too

[xdi1]

Both the core (win32, event handling, etc.) and the rendering pipeline generate garbage. We should probably treat them as separate problems.

Drawing (especially drawing texts) allocates significantly more than other activities. When there's no drawing hitches are much less frequent, and this may be good enough for certain use cases. However as long as per frame allocation is not 0 gc collections are inevitable.