A simple to medium complexity WPF app will be slower than its Winforms or Win32 counter part. It will use a lot more memory too. There may be ways around this but why can't MS optimize it instead of forcing every developer to jump through the same hoops?

Higher than "simple to medium" scale/complexity situations are probably their priority when it comes to optimisation, on the basis that most smaller scale/complexity apps won't experience the difference and those that do can be tweaked by the programmer. A major factor to consider when optimising anything particularly something as generic as a large framework is that an optimisation for small scale situations can have a detrimental effect on larger ones (and vice-versa, though as problems are more noticeable on larger scales of size or complexity optimising for that at the expense of the smaller situations is the better over-all choice in many cases).

Exactly. Bubble-sort is really fast for more-or-less pre-sorted data. But it's terrible in the worst case.

This strikes me as a particularly un-HN-like comment. Accusatory tone is not a valued conversational technique here.

Be mindful of not slipping into the more emotional tone that some have observed nipping at the edges of the HN community.

(I don't mean to sound as if I'm speaking from a position of moral superiority, nor expertise with regard to the topic at hand. Just an observation and suggestion.)

P.S. For the record, I did not downvote anything. That is coming from elsewhere.

I can hardly afford the time it would take to do that.

Besides that, I think my assessment of the situation is solid. It is much more cost-effective to make your developers (who will follow you, as they have huge investments on your platform already and wouldn't be willing or able to switch) move the direction you want than move in the direction they want. In their position, being able to do whatever is convenient for them regardless of how inconvenient it is to their users, I'd do exactly the same.

It's a delicate act of balancing your inconvenience of moving along with your vendor and your cost of migrating to another. As long as the second half is kept high enough, they can do a lot of inconvenience on the first.

> The fact that most developers don't understand how the API works

This signals a usability fail in my mind.

They made it very easy to get things up and going, and easy to optimize if you understand that graphics and WPF work. Most people don't, which is why most OpenGL and D3D apps that haven't been heavily optimized over time are very slow; graphics are hard, even without the extra burden of understanding how your GUI layer functions. It's easy to shoot yourself in the foot with WPF, but it also makes it easy for people to design really efficient apps if they take the time to learn how it differs from other GUI toolkits.

I see it more like sometimes shit is just hard to do well, taking time and effort to learn, and some developers don't put in the required work to reap the rewards.

I did find the official WPF docs and examples rather simplistic. Most of the advanced stuff I luckily stumbled upon on forums or blog posts. Perhaps developers don't have enough information to build upon the simple examples.

I believe most, if not all, of MSDN now supports user-contributed content alongside the API refs.

Thus, it would serve your fellow developers if you were to annotate the lacking documentation with (1) example code or (2) pointers to the blog postings that you found.

Nah the API just uses a different pattern from the "classic" WinForm development that most developers are used to.

I think people are going on the assertion that every-day apps written with WPF (i.e. Visual Studio 2010) are a step back from their old GDI-based ancestors with respect to performance.

I mean we've had to buy a shit load of graphics cards to get acceptable performance on our (definitely not shoddy) kit.