Michael Lowe asked about performance of interop. I don’t have as many hard numbers as I would like, it’s on my (very long) to do list to do some profiling on a couple samples. But a couple thoughts.
All Avalon applications are ultimately inside a HwndSource — Window, Popup, and a few other classes internally use HwndSource. So there’s no performance penalty for using HwndSource instead of Window, if anything you’d probably save a small amount of working set by using HwndSource. I haven’t measured the per-instance cost of HwndSource, ie, create 2000 HwndSources. My gut feel is that most realistic scenarios involve fewer then 10 HwndSources, and the working set overhead will not be significant (the Avalon content you put inside that HwndSource is likely to be far greater). But, as any performance expert will tell you, if you’re really serious about perf, there’s no substitute for measuring your specific scenario.
HwndHost is not currently used to implement any parts of Avalon, but again, I would be surprised if it cost a significant amount of working set unless you use a ridiculous number of them.
WindowsFormsHost and ElementHost are built on top of HwndHost and HwndSource, respectively. The code for these classes isn’t all that big, and they don’t keep a lot of data structures, so the main concern is the working set overhead of loading Windows Forms itself.
All of the above is really only talking about working set. (and implicitly, any startup time impact as a result of working set) That’s because I really don’t expect any significant impact to execution speed — I haven’t seen any so far, and all of these interop classes do very little in the paths that are performance-critical (such as property invalidation, creating trees of elements, and doing layouts and renders).