NOTE: Some of the links to the MSDN forums were broken by Microsoft.
MSFT wants adoption of it's new ui toolkit which is for building client apps. So what does it do? It packages a 200 meg redistributable that you need to send with your app. Sorry Microsoft, my app is 5 megs, I'm not about to ship a 205 meg installer. ... you've pretty much guaranteed that my apps will be 100% wpf-free. Now i'm even more irate that i spent so much time learning the platform.
WPF is so terribly bloated, check below the top of the stack with the mouse click handler...
The bad news is WPF is a totally retained UI framework, meaning you don't really have access to much low level stuff to do any custom hi-performance stuff.
But whatever I do, I can not even get decent frame rates for a simple particle system with a few thousand particles. I tried several approaches (one big DrawingVisual, one DrawingVisual per particle, writing a custom animation, subscribing to CompositionTarget.Render, etc.).
Both graphics cards are fast enough to play FarCry in full resolution, so please don't tell me that I should just get a better graphics card. And by the way, I am quite sure that the bottleneck is not the graphics card but the scene graph management, which is of course CPU bound.
Several times in the past we have seen WPF applications become scrambled looking. When the screen becomes scrambled, the WPF windows will fill with various colored rectangles instead of the GUI UI. I have seen issues similar to this with DirectX programming when the backbuffer is not properly cleared.
I want to have a small asterisk pulsing at sevaral places of the screen to attract user's attention.
I have an asterisk image (several Paths and GradientBrushes) and I animate it's RenderTransform/ScaleTransform/ScaleX, Y from 0.8 to 1.5 and back forever.
But having 10 such asterisks at screen takes all processor time !
While beginning of the text is instantly viewable, the control seems to take between 5-10s to finish layout completely (I can see the scrollbar resizing). This behavior makes the control basically useless as an editor since some editing operations or a resize cause this "re-layout" to occur.
The GDI based app gives sub-second response times for scaling the same data. My WPF based prototype takes approx 10 times as long taking at around 1.5 seconds on zoom in and zoom out.
Avalon has some great stuff, but if I got invited to one more dog and pony with mock ups of how great it would be (when it worked), I would have screamed. The inmates got control of the features in the asylum and the result was a bloated product.
"I think most of the performance issues I see relate to the CPU, not the graphics card. FrameworkElement creation and layout just takes longer than it seems it should take. So for example it takes 3 to 4 seconds to create a page with about 200 controls in a StackPanel on an Athlon X2 4400. When I look for the bottleneck, it's the UserControl creation that takes up the time. Now it may be that I need to look for ways to optimize the UserControl, but when I compare the complexity of my page relative to something a web browser displays, I generally find WPF to be slow, from layout to object creation."
Slow object creation/Destruction
(VG.net can create 1 million Shapes in less than 1 second on a low end 1.7Ghz CPU)
Bugs with more than 100 elements
Slow bitmap creation compared to GDI+
Very slow GridView
Glitches with large object movement