Skip to main content
September 5, 2014

Introducing Win2D: GPU accelerated 2D graphics programming in the Windows Runtime

This blog was written by Shawn Hargreaves, Principal Dev Lead at Microsoft.

Today I’d like to share some information about work we are doing to make hardware accelerated 2D graphics APIs available to C# developers.

Win2D is a Windows Runtime API we’re working on to expose the power of hardware accelerated Direct2D graphics to Universal App (Windows 8.1 and Windows Phone 8.1) developers – very much a work in progress. The Windows Runtime supports several major programming languages (including C# and C++) to allow developers to leverage their existing skills and assets, provide a thoughtful and consistent API surface and be deeply integrated into the developer tool chain. Today, building a Windows Store app using DirectX requires native C++ and DirectX APIs that have been made available to the Windows Runtime. This model is more complex than the usual Windows or Windows Phone app because it provides flexibility and access to system resources at the expense of simplicity. As a result we have received consistent requests from the developer community for access to DirectX through C#, graphics solutions similar to System.Drawing, XNA and SharpDX. These solutions have different audiences, ranging from developers of line of business apps to 2D and 3D game developers. System.Drawing provides immediate mode 2D rendering in GDI+ through .NET but is not hardware accelerated and is unable to keep up performance-wise for today’s graphics needs. Win2D is our attempt to give developers more of what they’re asking for.

Win2D’s design makes it easier for a C#/C++ developer to use the full capabilities of the Direct2D API without it feeling like a walled garden. These APIs can be used with XAML to produce beautiful graphics apps with rich UI. The API is in the early stages of development and we have a minimal set of 2D drawing functionality already implemented. By no means is the API in its current state a complete representation of Direct2D in Windows Runtime. We believe that releasing the API early, even if it does not have all the Direct2D features, is useful. As a developer and potential user of the API you get the chance to influence the API design early and ultimately help build the best C#/C++ Windows Runtime 2D immediate mode rendering API.

Get your hands on Win2D here:

It may be useful to understand some of our design principles as you explore Win2D and start to formulate your feedback:

Principle #1: Our design philosophy states anything that is possible with the Win2D should also be possible with the underlying DirectX API. This means that no new “feature work” will be added to Win2D that is not already present in the native API. This keeps us honest about the role of the Win2D work as a means to expose the existing functionality to a broader set of developers.

Principle #2: Our second design philosophy is to provide a surface area that is much easier to use without being a sandbox. This means that a C# developer can access native DirectX APIs when need be or can accommodate already existing DirectX code in a Windows Store app.

Principle #3: Our third design philosophy is to share our code and progress with the open source community. Most of the interesting choices are made in the design of the Windows Runtime Direct2D APIs and not in their implementation. For this reason, we want to engage early with the developer community and gather feedback iteratively. We will share our feature backlog with the community to provide insight into upcoming features and their order. If you would like to see a feature light up early, we want to know about it.

If you want to write your next 2D game, data visualization app, image filter or anything else under the sun that requires 2D immediate mode rendering in C#/C++, we’d love to hear what you think of Win2D. As of today you can begin to combine your rendered content using Win2D with flexible user interface framework offered by XAML. This interop is now made seamless instead of requiring native C++ (and access to smart pointers and the C++ component extensions).

You can follow the progress of the project and learn more about it on its blog: