When to use WPF and when to use other technologies

WPF is not the end-all be-all of technologies (at least not yet ), so there are many cases where either you will still need to rely on other Windows APIs, or the other APIs are more appropiate for the task at hand. I would like to provide some guidance as to the scenarios involved for different technologies in this post.Since I am mainly a graphics geek, I am going to focus on WPF and the following APIs:
· DirectShow
· Direct3D
· GDI/GDI+
In future releases we will extend the functionality in WPF to cover additional scenarios, as well as improve the integration with other APIs, so the guidance here is subject to change. Your comments and requests are welcomed, to help us prioritize the scenarios that we should tackle first.The first concept that is going to be a common thread in dealing with many of these scenarios is HwndHost (HwndHost at MSDN and Nick's article on HwndHost). This enables you to take content that is drawn using other APIs and host it within your WPF application.There is a limitation with HwndHost in that you will not be able to apply some graphical transformations on the hwndhost content, like applying transparency or using it as a texture. Another limitation is that likely you are using unmanaged code to create the content in the hwnd, which means that this will not work in a XAML Browser Application (xbap).I am likely to follow up this posting with some background on the architectural decisions we made early on, as well as the big bets on technology trends we decided to place in late 2000/early 2001 as we started to design the WPF architecture.
WPF and DirectShowIf you want to do capture (audio or video), or have your own DirectShow filter graph, you will have to code directly to DirectShow in WPF v1. You will then take the content and host it in WPF through HwndHost.However, if all you want to do is play your own format, you can just provide a DirectShow CODEC for it, and then folks will be able to use the format through the Media element and fully integrate it as part of other WPF content, without limitations.WPF and Direct3DMy simple axiom on the 3D front is:if you already have domain knowledge in Direct3D (or OpenGL), you should stick with using Direct3D for WPF v1.Now, to provide more context on my guidance. We make 3D a lot easier to use in WPF, and by a much larger developer audience than the one that uses 3D today. We also make it usable on the Web (in a xbap), we make it print, we make it remote, and we make it easier to integrate 3D with 2D, UI controls, and Documents (including as part of XAML). But, in using WPF, you give up a bit of the flexibility and direct hardware control that you get with the lower level APIs. We also manage your data (sometimes I refer to this as "managed graphics", to go along with managed code) and in doing so there is a bit of overhead, which costs you some performance (this is very dependent on the scenario, and we are tunning this code to reduce the cost based on scenarios that early adopters are sending in, so don't wait if you run into problems).We did not optimize our architecture in this initial version for twitch games or high end scientific vizualization scenarios, so if you want to tackle something along those lines, give it a try and see if it meets your needs. Similar to the DirectShow case, once you get your content going, you use hwndHost to merge it with your WPF content.Some scenarios for this involve providing a new UI for a Direct3D based application, or hosting a 3D modeler/editor within your WPF application.WPF and GDI/GDI+For those interested in factoids - GDI and GDI+ are part of our team, and some of the WPF developers/program managers/testers were part of those efforts many years ago (and many of us were involved in VML as well).If you can't let go of raster ops, need 1-pixel wide lines, or need to load EMF/WMF files, then you will likely need to use GDI/GDI+, and then HwndHost. We are looking at how to tackle raster ops through effects, as well as provide scale invariant lines, in the future. WMF and EMF are a bit trickier, as we are trying to strike towards secure by default (even at the cost of functionality) and also because of expectations in terms of compatibility. I fully expect that some of you in the develop community will add value to the platform by developing EMF/WMF CODECs to be used within WPF applications.