There's been come dramatic speed improvements over the last few releases. I also find the WPF aspect of live messenger pretty engaging and pleasant, though i find a lot of other things about that program to be pretty poor. I feel like WPF is a lot like flash, both technically and in a lot of practical ways. A lot of people who make flash or WPF applications get carried away with gratuitous animations and graphics which turns the program into a sluggish memory hog. It is possible to write great and performant apps with wpf. Metrotwit and live messenger 2011 are two of those.

WLM2011 isn't a WPF application.

It's also not a long way from how people often say c# and java applications are all slow and terrible, but the problem if often that both platforms make it easier to write lazy code. there is nothing in each technology that prevents good applications being written in them and there are plenty of examples of that.

There is. It depends on the quality of the widget and windowing libraries provided on the platform and how well they wrap around native system features or imlement their own equivalents (as WPF does).

Java's Swing and AWT, for example, are designed to be as cross-platform as possible, so they don't expose Windows-only features, and miss out on other things (Aero button animations, for example, or proper spacing for Tab controls, things like that), and that's assuming developers use the "native" lookAndFeel option, which you have to explicitly set, otherwise you get the horrendous Sun-designed themes.

I'll admit that you can push things to get the right result, but in many cases that requires truely excessive amounts of work (such as implementing your own widget library from scratch, and no-one wants to have to do that). 95% of the time developers will use the libraries they're given and just get to work on their domain-specific coding. It doesn't matter to them if the library has a 750ms initialisation time with O(n^2) widget drawing time complexity because they don't want (or can't afford) to shift technology platforms. That's why I'm wary of suggesting anyone use WPF because by the time they realise that the end-product will be awful they've run out of time to fix WPF's shortcomings or move back to WinForms. End result: they push out a slow desktop application with horrendously anti-aliased text and widgets that don't respect the current system visual style and colour scheme.

The biggest problem with wpf afaics, is that it's easy to create interfaces that are unperformant. There's nothing intuitive to the programmer as regards to what they need to do to make sure the application always run fast on the targeted hardware. It takes a programmer who knows alot of the ins and outs of the framework to write a good app using it. knowing when to use bitmapCache is one major example.

"Performance" can refer to many things. Throughput, smoothness, latency, and so on. I'm seeing a trend in software lately to focus more on throughput so latency suffers. There are also many other qualiatative measures regarding how good a UI framework is. For example one issue with WinForms that irks me how if you have a Form instance with lots of controls on it (even just a lot of buttons and textboxes) things slow down tremendously (note this has nothing to do with double-buffering).