Messing with Direct2D

As I blogged about previously, the main bottleneck in the oscilloscope code was in the drawing of the charts, in my previous post I modified DynamicDataDisplay to optimise this, but I wanted to make a Metro version of my app, and didn’t want to convert that library over, so I thought I’d look at doing the drawing myself.

First off,  on Windows 7/.NET4 I used the SurfaceInteropHelper  which allows Direct2D to be hosted on a WPF control, to do the drawing, and found that the CPU usage dropped from 70% to just under 40% (the code’s not worth showing here, and my use of Direct2D was pretty simplistic).

For the Windows 8 consumer preview, I created an app that used the SwapChainBackgroundPanel . It wasn’t obvious how to do this in an app created from scratch, so I butchered the SDK sample Metro style DirectX  shooting game sample (XAML)

This control allows Direct2D and XAML to be mixed in a metro app, but the control needs to be at the root element. I can see how this would be OK for an app such as a game where it could make use of overlayed controls, but for an app such as mine where I’d like to have multiple charts drawn using Direct2D it’s not ideal. Also, it seems to force the skeleton of the app to be written in C++ (where it would be nice to have a C# app host the controls, with the C++ –hidden- ).

This was awkward, but not a blocker to implementing the app on Metro… the blocker was to do with accessing the microphone. There are new Media Foundation libraries to do that, which do interoperate with the new C# async features than DirectShow (expose awaitable types):


The new version of RX (2.0 beta) has a new CreateAsync method instead of having an overload of Create that takes the async lambda).

The code above is untested, as the blocker is in the new MediaCapture library:


There’s no way to create a lossless MediaEncodingProfile from which to extract the raw waveform.

I think I’ll leave this app on the backburner until at least a later beta.