chore(deps): Bump LiveChartsCore.SkiaSharpView.Avalonia from 2.0.0-rc5.4 to 2.0.0-rc6.1

[dependabot]

Updated LiveChartsCore.SkiaSharpView.Avalonia from 2.0.0-rc5.4 to 2.0.0-rc6.1.

Release notes

Sourced from LiveChartsCore.SkiaSharpView.Avalonia's releases.

2.0.0-rc6

After months of deep work and iteration, this release is finally here. There is XAML and hot reload support, reworked rendering for serious performance gains, and leaned hard into source generation to clean up and future-proof the codebase. Oh, and yes: LiveCharts is now AOT-friendly. It’s faster, cleaner, and more flexible than ever.

Seamless XAML Integration via Source Generators

LiveCharts now uses a powerful source generator that automatically transforms chart objects into designer-friendly UI components. For example, the generic LineSeries now has a corresponding XamlLineSeries class—part of a new naming convention where all UI-bound types are prefixed with Xaml. These components support data bindings, themes, hot reload, and full design-time integration:

This update dramatically improves the chart design experience. You can now fully style your charts using pure XAML, including theme support—no more ViewModel hacks or SkiaSharp dependencies just to customize visuals. In previous versions, UI customization often required logic in the ViewModel, which led to tightly coupled and less maintainable code. That’s now a thing of the past.

Documentation for XAML platforms has been fully updated (thanks, Copilot!) to showcase the new syntax. While the new XAML-first approach is recommended, the legacy syntax remains supported for backward compatibility.

On non-XAML platforms, MVVM usage has been phased out from examples across the site and repo, reflecting a cleaner, more platform-native approach.

Rendering is significantly faster

The rendering pipeline has undergone a deep overhaul. LiveCharts now manages SkiaSharp resources far more efficiently, with cleaner, hardware-accelerated implementations and tight synchronization with the OS screen refresh rate. We've also added custom integrations for UI frameworks—most notably, full support for the Uno Skia renderer.

SkiaSharp shaders, paints, and text blobs are now cached wherever possible, resulting in dramatically faster rendering times, smoother animations, and reduced resource consumption across the board.

Previously, LiveCharts relied on a fixed render loop that invalidated the control every ~16ms to simulate a 60 FPS refresh rate. While functional, this approach forced redraws regardless of whether the system was ready to display them. Now, rendering is fully delegated to the OS or UI framework. For example:

• On Blazor, we use requestAnimationFrame()
• On iOS*, CADDisplayLink
• On Android*, Choreographer
• On Uno Skia, a fully integrated render mode

This shift gives LiveCharts precise control over when and how frames are drawn—resulting in better performance and smoother visuals across platforms.

While it's hard to quantify the full performance gains (older versions lacked the benchmarking tools introduced in this release), the difference is substantial. Benchmarks in #​1915 and #​1936 offer a glimpse, but real-world usage shows even greater improvements.

As a bonus, there's now a "low-ish level" sample that removes the SkiaSharp dependency entirely—using Direct2D via Vortice—while still reusing 99% of the charting logic. This opens the door to even more rendering flexibility in the future.

Smarter Architecture with Source Generators

While this is an internal feature, it deserves the spotlight—because it radically simplifies how LiveCharts is built and maintained.

The library now uses a unified codebase, and a source generator automatically transforms core chart components into UI controls tailored for each supported framework. This means we write the logic once, and the generator handles the rest.

In previous versions, adding a new property to a chart control was a tedious, error-prone process. You had to manually define:

• An AvaloniaProperty for Avalonia
• A DependencyProperty for WPF
• A BindableProperty for MAUI
• Another DependencyProperty for WinUI (which behaves differently than WPF’s)
• Now Blazor, WinForm and Eto use regular properties.

It was repetitive, fragile, and frankly exhausting.

Now? It’s magical. The generator takes care of all the boilerplate, translating properties and control logic across frameworks automatically. The result: a cleaner, more maintainable codebase—and a much more enjoyable development experience.
... (truncated)

Commits viewable in compare view.

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.