| 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. |
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).