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.

LibreWPF owns the interop contracts and compile-time WindowsBase/PresentationCore compatibility projects. Portable Drawing belongs to LibreWinForms; core rendering belongs to ProGPU. See framework source ownership for source paths, exact dependency pins and unchanged package identities.

Full WPF application NativeAOT, native accessibility and portable printing remain unfinished. See the current support boundaries and delivery gates before relying on those capabilities.

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, Direct3D-style compatibility shims, GPU hit testing, and Silk.NET windowing/input. Direct2D/Win2D use a separate Windows-native interop and portable Canvas plan.
• 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 Showcase, ProGPU Avalonia package smoke, and no-source-change SDK smoke tests.

The maintained cross-platform priorities, compatibility policy, and ecosystem status are tracked in the LibreWPF cross-platform roadmap. The historical upstream Microsoft WPF roadmap remains below that LibreWPF section.

The portable hyperlink input contract records selected-owner content routing and its remaining application gates.

Linux windowing behavior

LibreWPF selects X11 when it runs in a Wayland desktop session that also exposes an XWayland DISPLAY. This preserves WPF desktop-coordinate behavior for Window.Left/Top, Window.DragMove, docking windows, and native popup placement. Set PROGPU_WPF_LINUX_WINDOWING=wayland to opt into native Wayland; native Wayland intentionally uses owner-composited popups because GLFW cannot position popup toplevels.

Libraries that need to choose a docking or floating-window strategy can call ProGpuWpfDiagnostics.TryGetWindowingCapabilities(...). The returned typed snapshot reports the actual backend and whether global positioning, interactive move, native popup windows, and owner-composited popups are available. Native Wayland reports global positioning and interactive movement as unsupported instead of silently pretending that an ignored absolute move succeeded.

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.70">
  <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.70">
  <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. Tag releases rebuild the immutable tagged source against the matching ProGPU GitHub release packages, verify the complete release bundle and provenance, then run the clean Windows AnyCPU package smoke before publication. The LibreWPF Build artifact is qualified for CI consumers, but its commit-qualified source.<sha> ProGPU dependencies are not public release packages. Manual release dispatch uses the same build and validation path for recovery publication.

LibreWPF Packages

ProGPU Packages

Build And Release

PROGPU_WPF_DEV_PACKAGE_VERSION=0.1.0-preview.70 PROGPU_WPF_PROGPU_PACKAGE_VERSION=0.1.0-preview.70 ./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.

Canonical WinForms integration is validated separately from the normal NuGet development path:

./eng/progpu-wpf-canonical-winforms-integration.sh

That clean-source gate requires the LibreWinForms and ProGPU submodule pins to agree, builds the upstream-derived System.Windows.Forms identity against ProGPU System.Drawing.Common, serializes the WPF reference/cycle foundation, and compiles both the real WindowsFormsIntegration reference and implementation assemblies. It treats unresolved or duplicate assembly closures as errors. The ordinary SDK/package path targets the coordinated ProGPU 0.1.0-preview.70 release. Its native runtime and static SDK are separate exact-version packages; both are required in the local feed. Preview.66 stopped during ProGPU publication after NuGet rejected its oversized native package; its published history is retained.

For a faster source-development loop, use the same qualified managed, theme, and harness project sets through the validation graph:

for target in \
  RestoreManagedTransport BuildManagedTransport \
  RestoreThemes BuildThemes \
  RestoreHarnesses BuildHarnesses
do
  ./.dotnet/dotnet msbuild eng/ProGPU.Wpf.ValidationGraphs.proj \
    -target:${target} -property:Configuration=Debug -verbosity:minimal
done

This preserves the normal compilers, analyzers, project ordering, all seven themes, Ribbon, and all four real-WPF harness builds. Restore and build remain separate processes so generated package properties are reevaluated correctly; independent theme and harness leaves build in parallel. On the current Apple arm64 development host, a warm 13-project sequence fell from about 45.3 seconds to 9.5 seconds. This is the inner loop only: the complete eng/progpu-wpf-sdk-ci.sh package, provenance, third-party, runtime, and live GPU gates remain required before a release.

GitHub workflows:

• LibreWPF Build runs the canonical WinForms source gate on Linux and 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, the canonical WinForms source integration report, docs/progpu-wpf-multi-window-render-device.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 [email protected].

Reporting security issues and security bugs

Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) [email protected]. 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.