Stabilizing Win2D


Back in September 2014 when first introducing Win2D, we said:

“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.”

How things have changed since then!  Win2D has grown into a rich and mature 2D graphics API.  We have recently caught up with the feature set of the underlying Windows graphics platform that Win2D is built on top of, supporting all the functionality of Direct2D and DirectImage plus a good chunk of DirectWrite.

We are now going to take some time to stabilize what we have built.  Once we are happy that everything is working well and our newer API designs are solid, we will remove the “experimental” tags, which currently warn that everything added since Win2D version 1.0.0 may be subject to change.

We still have a few loose ends to finish up, and will continue to fix bugs, support customers, and expose new features in Win2D when future versions of Windows add capabilities to the platform beneath us, but we have now successfully completed the typing-code-like-crazy-trying-to-catch-up-with-the-last-8-years-worth-of-Direct2D-features phase of the project.  Therefore, we will reduce the frequency of updates from our current biweekly cadence.  At a guess we’ll probably end up shipping more like once a month, but this is hard to predict as NuGet updates will now happen on-demand whenever we have worthy payload, rather than on a fixed schedule.

One of the most enjoyable parts of this project for me personally is the opportunity to engage 1-1 with developers, helping to understand your requirements and solve your problems.  That isn’t changing, so please keep the questions, bug reports and feature requests coming!  If you notice any flawed designs, now is the perfect time to point them out, while these APIs are still tagged as experimental...


Comments (6)

  1. Charlie Jackson says:

    Kudos to the Win2D team.  The work you have done thus far has been very, very helpful to our startup, particularly the work to give us a lot of access to DirectWrite.  Your work will probably mean a release of our first product will come months earlier than otherwise.

    Thank you to all the hard-working members of the Win2D team.  We really appreciate what you have accomplished.

  2. juanpablogc says:

    Jeje, typing-code-like-crazy-trying-to-catch-up-with-the-last-8-years-worth-of-Direct2D-features :). I really enjoy the way of Win2D, it would be great that Composition and Audiograph took the same way (I know there are rules). For me Win2D is like having new XNA with superpowers that improves XAML and WriteableBitmaps, I really enjoy the code of Win2D and the examples.

    I would like to have more time to read all the great documentation and I will try to make some request.

    The only thing I have in mind that I recently saw in the Direct2D effects is the Flood Effect (a bit weird). But could be a custom implementation of it from your great job a really cool feature. (At this moment I am using OpenCV with the Lucian Wischik) like having tolerance and starting point.

    I know it is not in the purposes of Win2D but well, It would make the job for an Win2D oriented app I am developing easier to develop.

    Thank you for the fantastic job and releasing updates so fast.

  3. The Flood effect in Direct2D isn't actually a flood fill like you are probably thinking.  This actually just fills an infinite surface with a constant color value (the name was taken from the SVG "flood" filter).  This functionality is exposed in Win2D as ColorSourceEffect.

  4. Anastasios-Antonios Toulkeridis says:

    Hello. Please i need help.

    I'm building a first-person Win2D game – you move the camera with the mouse. The problem is you can't move the camera indefinitely (say to the right) because the mouse pointer eventually exists the window bounds. Is it possible to programmatically move (re-center) the mouse pointer?

  5. Aaron says:

    Thank you very much for creating this. The biggest missing feature keeping me from moving from WPF to universal apps was the lack of a proper drawing API. I am excited to get started with your library. Thank you for your efforts.

    Is there a plan to, in some other project, provide GPU processing support for managed applications? That would be fantastic.

Skip to main content