Believe it or not modern browsers are a clear winner when it comes to graphics performance. Sure WPF has a slick animation API that can do all sorts of things and a super-flexible "lookless controls" model, but the second you try to display a lot of data with anything fancier than plain text, you're in for a world of pain. Endless optimizing of visual trees and layouts, large data binding operations causing opaque and difficult to control UI-thread freezes that disable all your wait indicators, half-baked UI-virtualization support, it's not fun. What takes me days of fiddling to get to acceptable with WPF I can do with HTML5 and an easy to use battle-tested library in a few hours.
Developed quite a lot of WPF apps but very rarely encountered performance issues you’re talking about.
> Endless optimizing of visual trees and layouts
Never did that.
> UI-thread freezes that disable all your wait indicators
I avoid doing lots of stuff in the UI thread. This is especially easy to do with modern .NET and async-await.
In addition, I design my wait indicators so they run on the composition thread, i.e. aren’t affected by the UI thread being stuck.
> half-baked UI-virtualization support
For me it usually works OK but I agree there’re probably some issues with this feature. I remember fixing problems when my code or markup did something that disabled the virtualization and ruined the performance. But it never took days, maybe a few hours.
P.S. The worst issues I’ve encountered with WPF wasn’t performance, it was stability. Once I’ve spent a lot of time debugging rare render thread crash. I still don’t know the reason but I’ve simplified my visuals a bit (namely, pre-multiplied a render transform with the complex vector shapes I was rendering) and the problem seems to gone for now. Another time it crashed when I opened a popup, and closed it too soon, like 10-20ms after the open. The popup was “loading, please wait…” progress bar so it only happened when opening very small files from very fast hard drives.
Like you, I have developed quite a lot of WPPF apps and still do (my day job!). I completely agree with all the points you made. Especially the point on composite control handling it's own wait indicator is spot on.
However, I believe @m_fayer is right too. The performance issue can creep up on you if you are not constantly watching it.
The weak-reference used by DelegateCommand in most WPF framework implementations - Prism, MVVMLight, Caliburn.Micro can cause extra headaches if one is not watching it. I have seen memory clogs with InputBindings; I have seen unexplaiined performance issues with ColumnSpan, RowSpan usages, and others issues I can't remember at the moment.
Buttom line is one needs to take C/C++ mindset to WPF to achieve optimal performance - that is you may have to have a strategy to clean up after yourself (just like pointers) and not rely too much on Garbage Collector (GC).
