Avalonia is entering a new phase. Beginning with v12, we are laying the groundwork for a new era in rendering. SkiaSharp will remain the default backend, but during v12 we will introduce experimental GPU-first rendering options. This marks the start of a deliberate transition: maintaining stability for existing applications while exploring next-generation rendering approaches.
This work ensures Avalonia remains the most reliable, high-performance platform for building cross-platform applications today, while preparing for the decade ahead.
Building on Solid Foundations
Avalonia's rendering has been built on SkiaSharp since our earliest days. Matthew Leibowitz's stewardship of that project deserves enormous recognition. His decade of work on the SkiaSharp bindings gave Avalonia, and the wider .NET ecosystem, a stable cross-platform foundation. It allowed us to focus on creating a modern UI framework without also needing to solve low-level graphics engineering.
That choice was exactly right for a small team establishing credibility. SkiaSharp's maturity meant Avalonia could grow quickly. Instead of reinventing graphics primitives, we concentrated our energy on building Avalonia's unique features and ensuring developers had a productive and consistent API.
But projects evolve. A strategy that works when you are a startup with a handful of engineers is not always the right one for a company with dozens of engineers and thousands of customers depending on the technology.
The Insurance Policy
Several years ago, we made a quiet but significant investment. Recognising how central rendering is to Avalonia's success, we developed our own Skia bindings as an internal project.
This was not because we were unhappy with SkiaSharp. It was a contingency plan. Any time an entire platform relies on a library maintained primarily by one person, however talented, it creates risk. Our goal was to ensure that if SkiaSharp ever became unsupported, Avalonia would not be left vulnerable.
That internal project required a five-figure engineering effort, but it gave us optionality. We could keep using SkiaSharp with confidence, knowing that if it faltered, we had a path forward that did not involve emergency rewrites.
We deliberately chose not to release those bindings publicly. They were functional and in some ways already better optimised for Avalonia's use cases than SkiaSharp, but we believed avoiding ecosystem fragmentation was more important than the modest technical advantages they offered at the time.
SkiaSharp has remained a mature and supported project, and we've benefited from its stability while retaining the option of independence if circumstances required it.
A New Chapter: Exploring Vello
Avalonia UI today is fundamentally different from the company we were just a few years ago. Our engineering team has tripled in size and we serve thousands of customers, including Fortune 500 enterprises running mission-critical systems on our platform.
This scale brings enormous responsibility, not just to our direct customers, but to the entire .NET ecosystem that relies on our technical decisions. At our current scale, it is both possible and responsible to invest in exploring the future of rendering.
Why Vello
Optimising Skia provides a strong foundation, but we're also exploring what GPU-first rendering could bring to the platform. Among several approaches we're investigating, Vello, a modern graphics engine written in Rust, has shown particularly interesting results.
Unlike traditional pipelines, Vello is GPU-first by design, meaning it takes full advantage of modern graphics hardware rather than treating the GPU as an optional accelerator.
Inspired by early community experimentation with GPU rendering, we've been developing experimental Vello bindings to better understand its potential.
We're sharing this work early and will be publishing these experimental Vello bindings in the coming weeks once we stabilise the API, allowing the community to explore and provide feedback on this technology alongside us. Note that these are just the bindings themselves. The full Avalonia backend integration will come later as the work matures. Initial stress testing shows intriguing results: tens of thousands of animated vector paths running at smooth 120 FPS, performance that would be extremely difficult for CPU-driven pipelines.
The early numbers are compelling. In certain workloads, we've observed Vello performing up to 100x faster than SkiaSharp. Even when running through a Skia-compatibility shim built on Vello, we've seen 8x speed improvements. If these gains hold up in real-world applications, they could enable dramatically smoother animations, lower latency, and far greater responsiveness.
The Multi-Backend Philosophy
Our goal is not to crown a single rendering backend, but to explore multiple paths and give developers choice while ensuring Avalonia remains at the forefront of cross-platform UI performance.
Avalonia has always been architected to support multiple rendering backends. We've had a Direct2D backend for years, though being Windows-only, it sees limited use. The vast majority of our users rely exclusively on the Skia backend and may not realise that Avalonia was designed from the beginning with this flexibility in mind.
Most applications will continue using SkiaSharp for its maturity and proven compatibility, just as they do today. Others may benefit from GPU-first approaches like Vello for specific workloads where such architectures excel. By expanding the available backend choices, we reduce risk, enable innovation without jeopardising stability, and ensure developers can select the best fit for their use case.
Roadmap and Transition
We are taking a measured, experimental approach. Avalonia v12 will continue to use SkiaSharp as the default backend, but it also marks the start of our exploration into next-generation rendering. During v12s development, we plan to introduce experimental GPU-first backends, giving developers an early opportunity to test and provide feedback on these technologies. These won't ship in 12.0, but may land in subsequent v12 releases as the experiments mature.
SkiaSharp will remain the default renderer for the foreseeable future, with no plans to change this. It will be fully supported for years to come, we value stability above all else, and changing the default renderer is one of the most significant technical decisions we could make.
This is not something that will be rushed or forced upon anyone. Our users can continue building with complete confidence; you are not being asked to migrate. Our experiments with technologies like Vello are about exploring additional options, rather than rushing into replacing what already works exceptionally well.
Why This Matters for Developers and Enterprises
For developers, this exploration could lead to applications becoming dramatically faster and more responsive, with new opportunities for graphics-intensive scenarios that were previously out of reach.
For enterprises, it provides confidence. Avalonia will not be left exposed to the fate of a single project. By exploring alternatives while maintaining SkiaSharp support, we can guarantee stability today while investigating innovations for tomorrow.
For the ecosystem, it signals that Avalonia is ready to explore and potentially lead in new directions. We will continue contributing where it makes sense, but we now have the capacity to investigate the next wave of rendering innovation in .NET.
Looking Forward
Rendering evolution is a multi-year journey, but one that positions Avalonia to meet the challenges of the next decade. GPUs are becoming more powerful and programmable, text rendering requirements are growing more complex, and safe systems programming languages like Rust are opening new possibilities. Avalonia is exploring all of it.
We are grateful for the foundation SkiaSharp gave us, and we remain committed to supporting it. But we're also excited to explore what's possible with emerging technologies like Vello, not as a definitive replacement, but as part of our ongoing commitment to pushing the boundaries of what's possible in cross-platform UI development.
The future of high-performance UI development is being written today, and Avalonia is actively exploring what that future might hold.
Avalonia is entering a new phase. Beginning with v12, we are laying the groundwork for a new era in rendering. SkiaSharp will remain the default backend, but during v12 we will introduce experimental GPU-first rendering options. This marks the start of a deliberate transition: maintaining stability for existing applications while exploring next-generation rendering approaches.
This work ensures Avalonia remains the most reliable, high-performance platform for building cross-platform applications today, while preparing for the decade ahead.
Building on Solid Foundations
Avalonia's rendering has been built on SkiaSharp since our earliest days. Matthew Leibowitz's stewardship of that project deserves enormous recognition. His decade of work on the SkiaSharp bindings gave Avalonia, and the wider .NET ecosystem, a stable cross-platform foundation. It allowed us to focus on creating a modern UI framework without also needing to solve low-level graphics engineering.
That choice was exactly right for a small team establishing credibility. SkiaSharp's maturity meant Avalonia could grow quickly. Instead of reinventing graphics primitives, we concentrated our energy on building Avalonia's unique features and ensuring developers had a productive and consistent API.
But projects evolve. A strategy that works when you are a startup with a handful of engineers is not always the right one for a company with dozens of engineers and thousands of customers depending on the technology.
The Insurance Policy
Several years ago, we made a quiet but significant investment. Recognising how central rendering is to Avalonia's success, we developed our own Skia bindings as an internal project.
This was not because we were unhappy with SkiaSharp. It was a contingency plan. Any time an entire platform relies on a library maintained primarily by one person, however talented, it creates risk. Our goal was to ensure that if SkiaSharp ever became unsupported, Avalonia would not be left vulnerable.
That internal project required a five-figure engineering effort, but it gave us optionality. We could keep using SkiaSharp with confidence, knowing that if it faltered, we had a path forward that did not involve emergency rewrites.
We deliberately chose not to release those bindings publicly. They were functional and in some ways already better optimised for Avalonia's use cases than SkiaSharp, but we believed avoiding ecosystem fragmentation was more important than the modest technical advantages they offered at the time.
SkiaSharp has remained a mature and supported project, and we've benefited from its stability while retaining the option of independence if circumstances required it.
A New Chapter: Exploring Vello
Avalonia UI today is fundamentally different from the company we were just a few years ago. Our engineering team has tripled in size and we serve thousands of customers, including Fortune 500 enterprises running mission-critical systems on our platform.
This scale brings enormous responsibility, not just to our direct customers, but to the entire .NET ecosystem that relies on our technical decisions. At our current scale, it is both possible and responsible to invest in exploring the future of rendering.
Why Vello
Optimising Skia provides a strong foundation, but we're also exploring what GPU-first rendering could bring to the platform. Among several approaches we're investigating, Vello, a modern graphics engine written in Rust, has shown particularly interesting results.
Unlike traditional pipelines, Vello is GPU-first by design, meaning it takes full advantage of modern graphics hardware rather than treating the GPU as an optional accelerator.
Inspired by early community experimentation with GPU rendering, we've been developing experimental Vello bindings to better understand its potential.
We're sharing this work early and will be publishing these experimental Vello bindings in the coming weeks once we stabilise the API, allowing the community to explore and provide feedback on this technology alongside us. Note that these are just the bindings themselves. The full Avalonia backend integration will come later as the work matures. Initial stress testing shows intriguing results: tens of thousands of animated vector paths running at smooth 120 FPS, performance that would be extremely difficult for CPU-driven pipelines.
The early numbers are compelling. In certain workloads, we've observed Vello performing up to 100x faster than SkiaSharp. Even when running through a Skia-compatibility shim built on Vello, we've seen 8x speed improvements. If these gains hold up in real-world applications, they could enable dramatically smoother animations, lower latency, and far greater responsiveness.
The Multi-Backend Philosophy
Our goal is not to crown a single rendering backend, but to explore multiple paths and give developers choice while ensuring Avalonia remains at the forefront of cross-platform UI performance.
Avalonia has always been architected to support multiple rendering backends. We've had a Direct2D backend for years, though being Windows-only, it sees limited use. The vast majority of our users rely exclusively on the Skia backend and may not realise that Avalonia was designed from the beginning with this flexibility in mind.
Most applications will continue using SkiaSharp for its maturity and proven compatibility, just as they do today. Others may benefit from GPU-first approaches like Vello for specific workloads where such architectures excel. By expanding the available backend choices, we reduce risk, enable innovation without jeopardising stability, and ensure developers can select the best fit for their use case.
Roadmap and Transition
We are taking a measured, experimental approach. Avalonia v12 will continue to use SkiaSharp as the default backend, but it also marks the start of our exploration into next-generation rendering. During v12s development, we plan to introduce experimental GPU-first backends, giving developers an early opportunity to test and provide feedback on these technologies. These won't ship in 12.0, but may land in subsequent v12 releases as the experiments mature.
SkiaSharp will remain the default renderer for the foreseeable future, with no plans to change this. It will be fully supported for years to come, we value stability above all else, and changing the default renderer is one of the most significant technical decisions we could make.
This is not something that will be rushed or forced upon anyone. Our users can continue building with complete confidence; you are not being asked to migrate. Our experiments with technologies like Vello are about exploring additional options, rather than rushing into replacing what already works exceptionally well.
Why This Matters for Developers and Enterprises
For developers, this exploration could lead to applications becoming dramatically faster and more responsive, with new opportunities for graphics-intensive scenarios that were previously out of reach.
For enterprises, it provides confidence. Avalonia will not be left exposed to the fate of a single project. By exploring alternatives while maintaining SkiaSharp support, we can guarantee stability today while investigating innovations for tomorrow.
For the ecosystem, it signals that Avalonia is ready to explore and potentially lead in new directions. We will continue contributing where it makes sense, but we now have the capacity to investigate the next wave of rendering innovation in .NET.
Looking Forward
Rendering evolution is a multi-year journey, but one that positions Avalonia to meet the challenges of the next decade. GPUs are becoming more powerful and programmable, text rendering requirements are growing more complex, and safe systems programming languages like Rust are opening new possibilities. Avalonia is exploring all of it.
We are grateful for the foundation SkiaSharp gave us, and we remain committed to supporting it. But we're also excited to explore what's possible with emerging technologies like Vello, not as a definitive replacement, but as part of our ongoing commitment to pushing the boundaries of what's possible in cross-platform UI development.
The future of high-performance UI development is being written today, and Avalonia is actively exploring what that future might hold.
Avalonia is entering a new phase. Beginning with v12, we are laying the groundwork for a new era in rendering. SkiaSharp will remain the default backend, but during v12 we will introduce experimental GPU-first rendering options. This marks the start of a deliberate transition: maintaining stability for existing applications while exploring next-generation rendering approaches.
This work ensures Avalonia remains the most reliable, high-performance platform for building cross-platform applications today, while preparing for the decade ahead.
Building on Solid Foundations
Avalonia's rendering has been built on SkiaSharp since our earliest days. Matthew Leibowitz's stewardship of that project deserves enormous recognition. His decade of work on the SkiaSharp bindings gave Avalonia, and the wider .NET ecosystem, a stable cross-platform foundation. It allowed us to focus on creating a modern UI framework without also needing to solve low-level graphics engineering.
That choice was exactly right for a small team establishing credibility. SkiaSharp's maturity meant Avalonia could grow quickly. Instead of reinventing graphics primitives, we concentrated our energy on building Avalonia's unique features and ensuring developers had a productive and consistent API.
But projects evolve. A strategy that works when you are a startup with a handful of engineers is not always the right one for a company with dozens of engineers and thousands of customers depending on the technology.
The Insurance Policy
Several years ago, we made a quiet but significant investment. Recognising how central rendering is to Avalonia's success, we developed our own Skia bindings as an internal project.
This was not because we were unhappy with SkiaSharp. It was a contingency plan. Any time an entire platform relies on a library maintained primarily by one person, however talented, it creates risk. Our goal was to ensure that if SkiaSharp ever became unsupported, Avalonia would not be left vulnerable.
That internal project required a five-figure engineering effort, but it gave us optionality. We could keep using SkiaSharp with confidence, knowing that if it faltered, we had a path forward that did not involve emergency rewrites.
We deliberately chose not to release those bindings publicly. They were functional and in some ways already better optimised for Avalonia's use cases than SkiaSharp, but we believed avoiding ecosystem fragmentation was more important than the modest technical advantages they offered at the time.
SkiaSharp has remained a mature and supported project, and we've benefited from its stability while retaining the option of independence if circumstances required it.
A New Chapter: Exploring Vello
Avalonia UI today is fundamentally different from the company we were just a few years ago. Our engineering team has tripled in size and we serve thousands of customers, including Fortune 500 enterprises running mission-critical systems on our platform.
This scale brings enormous responsibility, not just to our direct customers, but to the entire .NET ecosystem that relies on our technical decisions. At our current scale, it is both possible and responsible to invest in exploring the future of rendering.
Why Vello
Optimising Skia provides a strong foundation, but we're also exploring what GPU-first rendering could bring to the platform. Among several approaches we're investigating, Vello, a modern graphics engine written in Rust, has shown particularly interesting results.
Unlike traditional pipelines, Vello is GPU-first by design, meaning it takes full advantage of modern graphics hardware rather than treating the GPU as an optional accelerator.
Inspired by early community experimentation with GPU rendering, we've been developing experimental Vello bindings to better understand its potential.
We're sharing this work early and will be publishing these experimental Vello bindings in the coming weeks once we stabilise the API, allowing the community to explore and provide feedback on this technology alongside us. Note that these are just the bindings themselves. The full Avalonia backend integration will come later as the work matures. Initial stress testing shows intriguing results: tens of thousands of animated vector paths running at smooth 120 FPS, performance that would be extremely difficult for CPU-driven pipelines.
The early numbers are compelling. In certain workloads, we've observed Vello performing up to 100x faster than SkiaSharp. Even when running through a Skia-compatibility shim built on Vello, we've seen 8x speed improvements. If these gains hold up in real-world applications, they could enable dramatically smoother animations, lower latency, and far greater responsiveness.
The Multi-Backend Philosophy
Our goal is not to crown a single rendering backend, but to explore multiple paths and give developers choice while ensuring Avalonia remains at the forefront of cross-platform UI performance.
Avalonia has always been architected to support multiple rendering backends. We've had a Direct2D backend for years, though being Windows-only, it sees limited use. The vast majority of our users rely exclusively on the Skia backend and may not realise that Avalonia was designed from the beginning with this flexibility in mind.
Most applications will continue using SkiaSharp for its maturity and proven compatibility, just as they do today. Others may benefit from GPU-first approaches like Vello for specific workloads where such architectures excel. By expanding the available backend choices, we reduce risk, enable innovation without jeopardising stability, and ensure developers can select the best fit for their use case.
Roadmap and Transition
We are taking a measured, experimental approach. Avalonia v12 will continue to use SkiaSharp as the default backend, but it also marks the start of our exploration into next-generation rendering. During v12s development, we plan to introduce experimental GPU-first backends, giving developers an early opportunity to test and provide feedback on these technologies. These won't ship in 12.0, but may land in subsequent v12 releases as the experiments mature.
SkiaSharp will remain the default renderer for the foreseeable future, with no plans to change this. It will be fully supported for years to come, we value stability above all else, and changing the default renderer is one of the most significant technical decisions we could make.
This is not something that will be rushed or forced upon anyone. Our users can continue building with complete confidence; you are not being asked to migrate. Our experiments with technologies like Vello are about exploring additional options, rather than rushing into replacing what already works exceptionally well.
Why This Matters for Developers and Enterprises
For developers, this exploration could lead to applications becoming dramatically faster and more responsive, with new opportunities for graphics-intensive scenarios that were previously out of reach.
For enterprises, it provides confidence. Avalonia will not be left exposed to the fate of a single project. By exploring alternatives while maintaining SkiaSharp support, we can guarantee stability today while investigating innovations for tomorrow.
For the ecosystem, it signals that Avalonia is ready to explore and potentially lead in new directions. We will continue contributing where it makes sense, but we now have the capacity to investigate the next wave of rendering innovation in .NET.
Looking Forward
Rendering evolution is a multi-year journey, but one that positions Avalonia to meet the challenges of the next decade. GPUs are becoming more powerful and programmable, text rendering requirements are growing more complex, and safe systems programming languages like Rust are opening new possibilities. Avalonia is exploring all of it.
We are grateful for the foundation SkiaSharp gave us, and we remain committed to supporting it. But we're also excited to explore what's possible with emerging technologies like Vello, not as a definitive replacement, but as part of our ongoing commitment to pushing the boundaries of what's possible in cross-platform UI development.
The future of high-performance UI development is being written today, and Avalonia is actively exploring what that future might hold.
