LibreWPF ProGPU Port

This branch ports WPF onto the ProGPU/Silk.NET platform while reusing as much managed WPF code as possible. The public package brand is LibreWPF, with the custom SDK package LibreWPF.Sdk, so an existing WPF app can switch the project SDK and keep normal WPF source and XAML unchanged.

Current focus areas:

• Reuse WPF managed code for application model, dependency properties, layout, controls, data binding, documents, XAML, resources, themes, and the XAML compiler.
• Replace Windows-only MIL/D3D rendering with ProGPU WebGPU composition, shaders, DirectX-compatible shims, GPU hit testing, and Silk.NET windowing/input.
• Package the runtime as a preview SDK and NuGet set that can be consumed from a local feed or NuGet.org.
• Keep third-party validation active through basic WPF apps, Xceed Toolkit/AvalonDock, Xceed paid Toolkit/DataGrid, SciChart MVP, ProGPU Avalonia package smoke, and no-source-change SDK smoke tests.

Upstream WPF Synchronization

The current LibreWPF development line includes dotnet/wpf through upstream commit 1131ae499da9687fcd7c5b25cea7ac37f5885c61 (Source code updates from dotnet/dotnet (#11770), 2026-07-10). This pinned commit is the auditable upstream baseline for the next preview; later upstream commits are not implied.

Upstream updates are integrated periodically on progpu-rendering-port as explicit merge/sync commits. Each update must preserve the portable typed contracts, pass the full LibreWPF SDK and package-mode application gates, and update the baseline recorded here. Published preview tags remain immutable, so a consumer can combine the LibreWPF tag commit with this recorded upstream baseline to identify the exact managed WPF source lineage.

Getting Started: Switch From WPF To LibreWPF

LibreWPF is packaged as an MSBuild SDK so normal WPF apps can move to the ProGPU/Silk.NET platform through the project file first. Keep your application code, XAML, resources, and existing package references unchanged unless the app uses Windows-only interop or unsupported native graphics APIs.

1. Start from an existing SDK-style WPF project and keep a clean commit of the working WPF version.

2. Make sure the project targets the supported preview TFM:

<TargetFramework>net10.0-windows</TargetFramework>
<UseWPF>true</UseWPF>

LibreWPF.Sdk sets EnableWindowsTargeting when needed, so cross-platform builds can still use the Windows-shaped WPF API surface while running through the portable ProGPU host.

Windows is a supported LibreWPF runtime target alongside macOS and Linux. The net10.0-windows target framework preserves the WPF API contract; it does not select the Windows-only MIL renderer. Windows RIDs consume the same portable LibreWPF.Transport package and ProGPU/Silk.NET runtime graph, without RID-split runtime.win-* LibreWPF companion packages.

3. Change only the project SDK.

Before:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net10.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
  </PropertyGroup>
</Project>

After:

<Project Sdk="LibreWPF.Sdk/0.1.0-preview.17">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net10.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
  </PropertyGroup>
</Project>

Older projects that still use Microsoft.NET.Sdk.WindowsDesktop should make the same SDK change and keep the existing WPF properties.

4. Keep existing app dependencies in place. For example, a Toolkit app only changes the SDK line:

<Project Sdk="LibreWPF.Sdk/0.1.0-preview.17">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net10.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Extended.Wpf.Toolkit" Version="5.1.2" />
  </ItemGroup>
</Project>

5. Restore and run the app normally:

dotnet restore
dotnet run

6. Treat Windows-only interop, direct Win32 calls, D3DImage, raw DirectX use, custom HWND hosting, and unsupported native graphics APIs as the first compatibility review points. Normal WPF managed code, XAML, bindings, controls, resources, and themes should remain source-compatible as the port fills out.

NuGet Packages

The preview package set is defined in eng/progpu-preview-package-list.sh and validated by the release workflow.

LibreWPF Packages

Package	NuGet	Purpose
LibreWPF.Sdk		Custom MSBuild SDK that redirects WPF apps to the ProGPU/Silk.NET platform.
LibreWPF.ProGPU		WPF-to-ProGPU host, retained/source replay bridge, Silk.NET input/windowing, and compositor adapter.
LibreWPF.Transport		Ported managed WPF transport assemblies, refs, themes, XAML build tasks, and runtime metadata.
LibreWPF.Interop		Shared WPF interop contracts consumed by the WPF bridge and ProGPU runtime.

ProGPU Packages

Package	NuGet	Purpose
ProGPU.Backend		WebGPU device, swapchain, Silk.NET windowing, and platform backend services.
ProGPU.DirectX		DirectX-compatible facade for SciChart and future D3D-style interop on ProGPU/WebGPU.
ProGPU.Transpiler		Shader/source transformation helpers used by generated GPU pipelines.
ProGPU.Compute		Compute pipeline helpers for GPU effects, indexes, and acceleration structures.
ProGPU.Vector		Vector paths, geometry, brushes, pens, and rasterization data models.
ProGPU.Text		Text layout, glyph metrics, and GPU-ready text rendering helpers.
ProGPU.Scene		Scene graph, compositor commands, retained visuals, effects, and presentation primitives.
ProGPU.Layout		Measure/arrange layout substrate shared by ProGPU UI adapters.
ProGPU.Virtualization		Virtualization helpers for large retained visual and item surfaces.
ProGPU.WinUI		WinUI-shaped controls and app model implemented on ProGPU.
ProGPU.Avalonia		Avalonia integration and compositor backend adapter used by package smoke validation.
ProGPU.SkiaSharp		ProGPU-backed portable SkiaSharp compatibility shim used by drawing and imaging adapters.
ProGPU.System.Drawing.Common		ProGPU-backed portable System.Drawing.Common compatibility shim for LibreWinForms and GDI-style callers.

Build And Release

PROGPU_WPF_DEV_PACKAGE_VERSION=0.1.0-preview.17 ./eng/progpu-wpf-sdk-ci.sh

The SDK CI script stages ProGPU runtime packages, builds managed WPF transport assemblies, LibreWPF.ProGPU, and LibreWPF.Sdk, then audits the packages, writes the preview manifest, creates and verifies the release bundle, and runs package-mode SDK smoke tests. Public releases consume the hash-identical packages from the matching ProGPU GitHub release instead of repacking or republishing them.

GitHub workflows:

• LibreWPF Build runs the SDK package/no-source-change smoke on macOS.
• LibreWPF Docs verifies README and release docs against the preview package list.
• LibreWPF Release builds preview packages/bundle artifacts and can publish to NuGet.org with NUGET_API_KEY.

See docs/progpu-wpf-release.md and the ongoing porting reports in reports/.

Original Upstream README

Windows Presentation Foundation (WPF)

Windows Presentation Foundation (WPF) is a UI framework for building Windows desktop applications.

WPF supports a broad set of application development features, including an application model, resources, controls, graphics, layout, data binding and documents. WPF uses the Extensible Application Markup Language (XAML) to provide a declarative model for application programming.

WPF's rendering is vector-based, which enables applications to look great on high DPI monitors, as they can be infinitely scaled. WPF also includes a flexible hosting model, which makes it straightforward to host a video in a button, for example.

Visual Studio's designer, as well as Visual Studio Blend, make it easy to build WPF applications, with drag-and-drop and/or direct editing of XAML markup.

As of .NET 6.0, WPF supports ARM64.

See the WPF Roadmap to learn about project priorities, status and ship dates.

WinForms is another UI framework for building Windows desktop applications that is supported on .NET (7.0.x/6.0.x). WPF and WinForms applications only run on Windows. They are part of the Microsoft.NET.Sdk.WindowsDesktop SDK. You are recommended to use the most recent version of Visual Studio to develop WPF and WinForms applications for .NET.

To build the WPF repo and contribute features and fixes for .NET 8.0, Visual Studio 2022 Preview is required.

Getting started

• .NET 6.0 SDK, .NET 7.0 SDK, .NET 8.0 SDK, .NET 9.0 SDK
• .NET Preview SDKs
• Getting started instructions
• Contributing guide
• Migrating .NET Framework WPF Apps to .NET Core

Status

• We are currently developing WPF for .NET 10.

See the WPF roadmap to learn about the schedule for specific WPF components.

Test published at separate repo Tests and have limited coverage at this time. We will add more tests, however, it will be a progressive process.

The Visual Studio WPF designer is now available as part of Visual Studio 2019.

How to Engage, Contribute and Provide Feedback

Some of the best ways to contribute are to try things out, file bugs, join in design conversations, and fix issues.

• This repo defines contributing guidelines and also follows the more general .NET Core contributing guide.
• If you have a question or have found a bug, file an issue.
• Use daily builds if you want to contribute and stay up to date with the team.

.NET Framework issues

Issues with .NET Framework, including WPF, should be filed on VS developer community, or Product Support. They should not be filed on this repo.

Relationship to .NET Framework

This code base is a fork of the WPF code in the .NET Framework. .NET Core 3.0 was released with a goal of WPF having parity with the .NET Framework version. Over time, the two implementations may diverge.

The Update on .NET Core 3.0 and .NET Framework 4.8 provides a good description of the forward-looking differences between .NET Core and .NET Framework.

This update states how going forward .NET Core is the future of .NET. and .NET Framework 4.8 will be the last major version of .NET Framework.

Code of Conduct

This project uses the .NET Foundation Code of Conduct to define expected conduct in our community. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a project maintainer at conduct@dotnetfoundation.org.

Reporting security issues and security bugs

Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) secure@microsoft.com. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the Security TechCenter.

Also see info about related Microsoft .NET Core and ASP.NET Core Bug Bounty Program.

License

.NET Core (including the WPF repo) is licensed under the MIT license.

.NET Foundation

.NET Core WPF is a .NET Foundation project.

See the .NET home repo to find other .NET-related projects.