Can a standalone WPF application create an interface that looks like a Flash interface?

It seems like WPF was created as the application answer to Adobe's Flash. Silverlight is used for creating web pages. But, can that same functionality be pulled into a standalone WPF application. Scaleform allows Flash to be used within unmanaged C++ games. Can WPF be used to create the same type of interfaces? What I've read seems to make me believe it can. But, I haven't seen any sheetshots of applications that show this kind of interface.

• Is definitely game related, but you still might get a better answer on stackoverflow.com
– Iain
Aug 19 '10 at 16:12

WPF was created to provide a better way for Windows developers to build GUIs for desktop applications. Silverlight was created as an answer to Flash and re-uses much the WPF API but has a different implementation.

In theory you could use WPF to create the GUI for a game, but in practice you probably wouldn't:-

• Your game would depend on the .NET framework being installed. This isn't such a big deal any more, but still, it's one more thing to worry about not working.
• WPF uses Direct3D 9 to render. There is an extension to it which on Vista/Win7 and XP SP3 or later allows you to allocate a surface and share it between WPF and your unmanaged C++ game engine. You might have problems with DX10.1 or 11.
• The .NET runtime suspends all threads that are involved in any way with managed memory during a garbage collection. To avoid having your game loop suspended you need to come up with a way of exchanging data between your unmanaged code and the .NET runtime that avoids calling into the .NET runtime via interop. Probably you'd have a shared area of unmanaged memory that you both have access to and synchronise using umanaged threading primatives.
• Here's the real problem though: If you went down this route you'd be handing over control of your window to WPF. You just get to supply WPF with a D3D surface containing your final 3d render and then it composites that with whatever it has generated before presenting it. You'd be locked to WPF's refresh schedule and there's also no chance of going full-screen in the way that 3d games normally do.

There is a possibility that this situation could be rescued though. There is an open-source re-implementation of .NET called Mono. They have a sub-project called Moonlight which is a re-implementation of Silverlight. With source code available there's a possibility it could be integrated in a similar way to Scaleform and allow you to build GUIs using Microsoft's excellent Expression Blend authoring tool. I don't think anyone has done this yet so there are probably issues to be uncovered, but I'm just throwing it out there as an idea.

EDIT: It occured to me after adding this that maybe your interest isn't so much in leveraging authoring tools like Flash Studio or Expression Blend and maybe you just want to be able to draw high-quality 2d graphics fast. In which case there is the Direct2D API that Microsoft added in Windows 7 and then back-ported to Vista.

• FYI, the garbage collector has been substantially improved in .NET 4. It now supports background collection of all three generations of objects, but I don't know if/how the changes might affect issue #3 on your list. If anyone knows, please share :). Aug 20 '10 at 17:46
• Mono and Moonlight are MIT-licensed, so embedding one or both of them in a game is certainly doable (and is being done, for instance in Second Life). There has been at least one planned attempt at doing such an embedding of Moonlight itself for a game: tirania.org/blog/archive/2009/Nov-12-2.html#comment-22844845 (No idea if it happened/was successful or not, though.) Oct 11 '10 at 3:52

You can definitely create similar kinds of interfaces in WPF, but integrating them into a Direct3D game is problematic. You can host Direct3D content within WPF (via D3DImage), but your 3D content would be composed into the WPF application, so rendering becomes dependent on WPF. Consequently, you might see relatively poor performance, as you are limited by WPF's frame rate. Also, as U62 noted in his comment, WPF can only host Direct3D 9 content (as opposed to Direct3D 10/11). However, you might be able to get around this, as IDirect3DDevice9Ex is capable of sharing resources between devices. Therefore, you could potentially create a shared render target in Direct3D 10 or 11 and bring it into WPF via an intermediate IDirect3DDevice9Ex device. Jeremiah Morrill discusses this technique here.

An alternative, though far from elegant, would be to render your WPF UI in a separate layered window above the Direct3D content, as described here.

There are also ways to access WPF's internal Direct3D surface, which would give you a way to host WPF content in an external Direct3D scene (instead of the other way around). However, this is a rather nasty hack and could easily be broken by future WPF releases.

Of course, none of this is relevant if you don't actually need to interoperate with Direct3D. Games that don't require complex 3D graphics can certainly be developed completely in WPF. WPF does have some simple 3D facilities at its disposal, though they are generally insufficient for anything beyond primitive shapes with simple textures. It also supports custom pixel shaders, though there are many restrictions (e.g. they must be single-pass effects).