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 - verymuch 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 the 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.

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).

We have nuget binaries on our backlog (github.com/…/Backlog) but this is currently quite a long way down. Doing this is not completely straightforward as shipping complied code requires us to figure out some security issues around signing and so on.

We're very interested in feedback from you and others on the ordering of the backlog. Happy to rearrange things if there is a consensus about what is the highest priority to get done next.

In the short term, can you describe what build trouble you are seeing?

I like the idea of Win2D a lot, because I (being a C# developer) just can not get comfortable with C++. Can you already say something about the performance difference between C#-Win2D instead of C++-DirectX.

First let me say we are really happy to see you guys making this. Allowing custom drawing in WinRT/C# is something we've been looking to have for a while now. I would also ask that you implement this if possible to support WPF as well so that code can be reused across desktop and Store apps.

We are planning on working on a specialized Windows Store drawing app (possibly open source) that is geared towards use of pen input on devices such as Surface Pro 3. This is a spare time project that we are planning on starting in a month or so but have been doing some quick preliminary research on how to make such an app. So far, our best option seemed to be SharpDX but coming from a C# background, that's still very low-level and not so easy to use. That's why we were thrilled to see what you're doing here with this, since it sounds like it's just what we're looking for.

Since we're making a drawing app for this first usage of Win2D, we need to be able to do things like render bitmap data quickly on a drawing surface that spans the screen and can accept input without lag. Being new to DX in general, I'm not sure yet the best way to do that. Our main drawing surface needs to support zooming in on the bitmap, grid lines, etc. Then we also need support for rendering layer thumbnails in a separate layers list pane. The drawing surface doesn't need to refresh too often, it's only when scrolling/zooming takes place, or the pixels are altered by input.

From your backlog list, it seems like we still might need more work from you in terms of bitmaps such as drawing directly on a bitmap and getting/altering pixels. It would be nice if we could just invalidate certain bound ranges of a bitmap for repainting too such as if the user just paints a single pixel.

If you have any suggestions on implementing the above, please reply back.

As for the build issues, I tried this on both of my VS 2013 update 3 machines:

Ronald: I will try to finish a blog post with performance data within the next couple of weeks. We did some measurements a month or so back that looked quite promising, but have since changed a bunch of stuff which in theory should greatly reduce overhead compared to what we had back then, so I don't want to quote figures here that might no longer be true!

In general you should expect C#/Win2D to add some overhead compared to C++/D2D (can't make a layer without adding SOME overhead along the way) but this cost will be a fixed percentage and quite low. I don't expect there to be many (if any) cases where perf is a deciding factor when choosing between the two.

Bill: Win2D sounds perfect for the app you describe! You will definitely need drawing onto a bitmap, which we are working on right now so that'll be arriving Very Soon(tm). Outside of that I think you should be all set. We have a bunch of stuff on the backlog that will simplify some things and give more efficient options for working with layers and cropping subregions out of a bitmap, but I'm pretty sure you could get your app done with just what we have today. And if you don't start for a month or so, we will have MUCH more API in place by then.

zerhacken: regarding the CLA, I have a confession to make – I have absolutely no idea how we're going to collect these! We got as far as realizing that we needed some sort of agreement to keep everything safe for all involved, and got the lawyers to give us the text for what this agreement should say, but have not yet worked out the logistical side of things. What can I say – this is the first time I did a big open source project at Microsoft, so I'm figuring lots of the details out as we go 🙂

Just wondering if there's any chance this will work in Background Tasks (Windows Phone 8.1 + Win8.1) – specifically for rendering of live tiles + lock screen images in future (if that gets supported in upcoming WP Winrt API's).

This sounds like a very interesting project. However I'd love to see some more comments and explanations on why earlier project simply wasn't good enough when they from my opinion more or less filled the same gap as Win2D appears to fill in the near future. Managed DirectX and XNA were however cancelled despite the frustration from the community which in response created open source alternatives to save the projects and customers that had invested in technology Microsoft introduced.

I understand that the future is "uncertain", but is this technology something that we should dare invest in or will it see the same fate as it's earlier incarnations? What makes Win2D "differ" from the previous ones?

> One question though can I use it as a ui framework for a dx11 application ?

Win2D can interop easily with native D2D (microsoft.github.io/…/Interop.htm) so you can absolutely use it for just part of a DX11 application. It's not really a UI framework, though, but a 2D drawing API. Depending on what sort of UI you need, Win2D might be useful, or XAML might be a better choice.

> I'd love to see some more comments and explanations on why earlier project simply wasn't good enough

Win2D and XNA overlap in the sense that both can draw graphics and are accessible from C#, but they're actually fairly different designs targeted at different scenarios. XNA was all about games, and its graphics API focused more on the 3D side of things, while Win2D is all about 2D graphics covering a wide range of app requirements. There are some places (such as 2D games) where these overlap and either technology could work well, but if you are creating eg. a map visualization that requires thick lines and localized text with high quality antialiasing, Win2D will make that easy while XNA would help you not at all.

> Managed DirectX and XNA were however cancelled despite the frustration from the community which in response created open source alternatives

Would it be possible to get this to work with WPF/XAML applications on the desktop? If its at all possible, would a pull request with such functionality be accepted or would the pull request have to live off in its own fork of the library?

I personally would love to have something like this for a WPF program I'm working on for work because we're making heavy use of XNA and it's not that adequate for 2D drawing which is the only kind of drawing I'm doing in the program.

> Would it be possible to get this to work with WPF/XAML applications on the desktop?

I'm not sure how that could work as Win2D is a Windows Runtime API, and I don't think you can use WinRT from a WPF application. I'm far from expert on WPF though, so might just be unaware of some way to do that.

I'm far from expert with WinRT personally, though I've got a better idea with WPF, but I think that all that would need done is wrapping the WinRT stuff in compiler conditional statements and implement the WPF/.NET equivalents. I'll see if there is anything I could try to do with it, hopefully I can make some progress with it, though I probably will wait for the library to fill out some more before attempting it, plus I would need some time to study the code base and see what all needs work.

We have retained mode API in the form of WPF (though a bit forgotten by MS), but no immediate mode one. GDI is not accelerated anymore, GDI+ hasn't been from the very beginning. So what is the Microsoft offer for managed developers in this area?

Abstract: We present a massively parallel vector graphics rendering pipeline that is divided into two components. The preprocessing component builds a novel adaptive acceleration data structure, the shortcut tree. Tree construction is efficient and parallel at the segment level, enabling dynamic vector graphics. The tree allows efficient random access to the color of individual samples, so the graphics can be warped for special effects. The rendering component processes all samples and pixels in parallel. It was optimized for wide antialiasing filters and a large number of samples per pixel to generate sharp, noise-free images. Our sample scheduler allows pixels with overlapping antialiasing filters to share samples. It groups together samples that can be computed with the same vector operations using little memory or bandwidth. The pipeline is feature-rich, supporting multiple layers of filled paths, each defined by curved outlines (with linear, rational quadratic, and integral cubic Bézier segments), clipped against other paths, and painted with semi-transparent colors, gradients, or textures. We demonstrate renderings of complex vector graphics in state-of-the-art quality and performance. Finally, we provide full source-code for our implementation as well as the input data used in the paper.

Can I ask why this is being released as a WinRT library and not a .NET library? As it stands, Win2D is going to be limited to Windows Store apps, which means abandoning 90% of the marketplace. Personally, I'm unwilling to commit to writing against a library which isn't supported on Windows 7 or other platforms. It's a shame, as there's definitely a need to have something at a higher level than the current DirectX wrappers.

Win2D does not ship as an inbox part of the Windows 10 API. That is, it is a Nuget package and you need to download this package into a project to use it. You don't get it as part of the normal Windows 10 SDK.