Rendering improvements

[beto-rodriguez]

This PR improves performance and efficiency on how the controls are drawn, this PR has no practical effect on Avalonia because all this PR does is already implemented/handled by Avalonia, LiveCharts just draws when and how Avalonia wants 😄.

1. GPU enabled by default

SkiaSharp 3 introduces hardware-accelerated views across all supported platforms. By default, LiveCharts now leverages GPU-backed views for rendering—offloading drawing tasks from the CPU to achieve smoother visuals and better performance.

Before initializing the chart, LiveCharts automatically probes the system’s GPU capabilities. If a suitable graphics context isn’t available (due to driver issues, platform limitations, or user configuration), LiveCharts seamlessly falls back to a CPU-rendered view to ensure reliability.

This adaptive strategy guarantees optimal performance when possible—and graceful degradation when necessary.

2. OS VSync

In previous versions, the chart relied on a fixed render loop that invalidated the control every ~16ms, simulating a ~60 FPS refresh rate. While this worked, it wasn’t optimal—it forced redraws regardless of whether the system was ready or willing to display them.

This PR introduces native VSync integration, allowing the OS or UI framework to dictate when a frame should be rendered. Why does this matter? Because the rendering now aligns with the system’s display pipeline:

🧠 Redraws only happen when the system can actually present them

🔋 Reduces unnecessary frame invalidations, saving power and CPU cycles

🎯 The FPS log now reflects real on-screen rendering, not just simulation ticks

Previously, the FPS counter measured how often frames were calculated, not necessarily drawn. With VSync in place, those numbers become truthful—frame pacing is accurate, rendering is smoother, and performance diagnostics are more meaningful.

The next table explains the ticker used on each OS, and compares them with the current method in the library (custom loop):

Results:

This benchmark compares rendering performance across major .NET UI frameworks on multiple platforms, LiveCharts now shares about 99% of the code between all UI frameworks, this test basically compares how efficient each UI framework is.

The next table show the Frames per second reached (FPS) and the render time it took for each frame in milliseconds:

{FPS} @ {render time in ms}

FPS indicates frame rate stability, while render time reflects per-frame latency.

OS	MAUI	Avalonia	Uno Native	Uno Skia Renderer
Windows	🟢97.62 @ 2.87	🟢 97.64 @ 2.26	*1 🔴 Crash	🟡 35.70 @ 2.69
Mac/Catalyst	🟢99.39 @ 2.97	🟢100.52 @ 2.57	🟢99.39 @ 2.97 *2	🟡 33.53 @ 2.97
Android	🟢74.93 @ 6.74	🟡 30.31 @ 9.24	🟢77.76 @ 7.14	🟢60.12 @ 4.07
iOS	🟢60.29 @ 5.24	🟢 60.22 @ 6.17	🟢60.29 @ 5.24 *2	🟢60.29 @ 3.20
WASM	🔵 Not Supported	🟠 18.44 @ 40.54	🟠24.32 @ 28.37	🟡37.95 @ 20.32
Ubuntu 24.04	🔵 Not Supported	🟢 58.69 @ 1.98	via SkiaRenderer	*3 🔴 Crash

Additional test made:

• Blazor WASM: 🟠24.28 @ 34.11 (using requestAnimationFrame)
• WPF: 🟢103.40 @ 2.66

Highlights

Avalonia consistently delivers high FPS on desktop platforms; Uno shines on WASM and has a consistent low frame latency, which means efficiency, while MAUI behaves performant across all the supported platforms.

Notes & Exceptions

• *1: Probably due SkiaSharp/issues/2803.
• *2: iOS/Mac Catalyst tests not run for Uno Native, expected similar to MAUI
• *3: Uno Skia fails on Ubuntu due SkiaSharp issue #3229

Used Versions

• SkiaSharp 3.119.0 (for Avalonia 2.88.x)
• Maui 9.0.90
• Avalonia 11.3.2
• Uno SDK 6.1.23

Devices tested:

OS	Specs
Windows	CPU: i7 10700 @ 2.90GHz, GPU: UHD Graphics 630 128MB, Screen refresh rate 100Hz
Android	Samsung A35 (SM-A356U1)
Mac	Mac Mini M4, 24 GB RAM, Screen refresh rate 100Hz
iOS	iPad 8th generation, screen updates at 60Hz
Ubuntu	The Mac mini above, running a VM on UTM

About the test

Release build using the Lines/Zooming example in this repo, move the chart from left to right 10 times, on desktop devices and WASM the chart size was of 900x500 pixels.