When I first started work on DirectCanvas, the idea was to give .NET developers access to a rich, high performance, 2D drawing API.  I took the project so far, but gained a level in frustration and decided to restart the whole project, starting with C++.

Why C++?

The number one reason is performance.  When developing anything “high performance” a  managed language is like bringing a Yugo to the drag strip.  You can drop as many horses into that Yugo, but you are still using it beyond what it was designed for. You begin to put a lot of mental bandwidth into writing around the GC, and still you and up with something that isn’t as fast as it could be.  I hate leaving performance on the table, don’t you?

Another reason is productivity.  Given all the APIs DirectCanvas would eventually use are written in native, it’s just easier to also write in native code. I was using SlimDX for the Direct3D interop in the .NET version of DirectCanvas.  I can’t say enough nice things about SlimDX and would suggest it over anything else to anyone doing D3D in .NET.  But there’s things that SlimDX didn’t cover, like WIC, which I ended up having to write interop code for.  I wrote it using .NET COM interop, which I came across RCW issues which I promptly got fed up with and decided to make it work well, I’d have to rewrite the interop code yet again in CLI/C++.

The third reason, is “C++ devs need a drawing library too.”  This might sound odd as Direct2D, Direct3D, WIC, etc, are already C++ APIs, so devs already have that support.  But in the end, just because one is fluent in C++ doesn’t mean they want to understand the GPU, image processing, media or any other of the facilities DirectCanvas abstracts.

What about .NET?

I still plan on supporting .NET via a wrapper in the future.  It is not really a high priority until the C++ code is to a solid state.  I think it is important to have eventually as it increases the developer base of the library.  Also a lot of performance can be preserved by just going through one managed –> native abstraction layer with most things still “managed” in the native code.

What is the current state of native DirectCanvas?

I’ve been using the .NET version as a reference implementation.  Slowly rewriting all the features to mostly match, but in native code. 

Compositor – The glorified batch sprite is mostly complete.  This allows for extremely high number of sprites (500k at 60 FPS on my machine) and supports blend modes (eg, Additive, Subtractive, etc).

MediaPlayer – This plays media and is backed by MediaFoundation, so it supports GPU accelerated decoding of VC1 and H264 video.  I have much of this completed, but still needs a handful of features to make it worthwhile.  I’ve totally thrashed some Microsoft samples for implementing a custom EVR and player, but still it was a huge undertaking that still needs a little more love.

VideoBrush – Allows you to use a MediaPlayer as a brush.  Because it is a brush, it can be painted within any vector geometry or stroke around geometry.

SolidColorBrush – Nothing fancy here

DrawingLayer – This is where all drawing happens, a conceptual GPU backed bitmap.  Right now only supports drawing rectangles, ellipses and MediaPlayers but sooner or later it will support all geometry.  That shouldn’t be too hard as it’s mostly wrapping up Direct2D API.

D3D9 GPU Support – I’ve built in support for a compatibility mode so folks can use this on DX9 GPUs.  There are some restrictions with that enabled, but mostly stuff that can be worked around.

HwndPresenter – This lets you present your drawing layer to any Hwnd window.

Where’s the codes?

You can download a current copy of it here, but I do warn that everything is in a state of flux and refactoring happens on a weekly basis.  Don’t expect to much. It does require the June 2010 Direct SDK and the Windows SDK to compile.  Also remember release builds and release builds w/o the debugger attached have the best performance (duh!).