(I’m getting to the point in a roundabout way… you can skip directly to the point below if you want.)
When I started working on my WPF-Wii tutorials, my first Wii project was the initial version of the WPF-Wii Visualizer.
However, I quickly got tired of writing the code for handling events and transferring the data from the Wiimote library to my application. So (like any noble geek would do) I wrote even MORE code to solve the problem, not only for myself, but for generations to come.
I’ve spend the last week writing a Wii-To-WPF library that shovels the Wiimote properties into properties that use the INotifyPropertyChanged WPF interface. This will allow anyone to connect to the Wii through the WPF data binding. It’s super cool.
(A point of note, I posted an early version of this library. Ignore it. I’m putting up a much improved version in the next couple days.)
The Point
But I had no idea how moving from a basic data transference and event handling to the INotifyPropertyChanged interface would affect my performance.
Here are some screenshots of Perforator (a WPF performance monitoring application) monitoring my WPF-Wii Visualizer in its code-heavy iteration:
I don’t know what all those numbers mean, but the one I’m interested in is the frame rate. As a designer, smoother motion is good… especially if I’m trying to design a multi-point application. A frame rate of 27 isn’t too bad, but this is the best I got. The frame rate usually hovered around 20, dipping as low as five.
Now… this is what I got when I was binding the data through the XAML (absolutely no code whatsoever):
And this was the worst I got. My frame rate was always in the mid 60s and would spike up to 80. Take note that I’m not changing the interface at all. In fact, I’m running the binding version at a handicap (it’s tracking four infrared points instead of the original two).
Exact same XAML … except that the XAML properties are data bound from within the XAML and not assigned via the C# code.
So, lets take an account of the WPF INotifyPropertyChanged interface:
- Allows DataBinding
- Permits code-light or code-free interface design
- Drastic improvements to performance
Use it!
Enough said.
Beware of Perforator. The framerate shown in Perforator tends to increase when your app is getting overloaded and slowing down. It even shows 100+ framerate when the monitor can really do only 60fps. Use CompositionTarget.Rendering event with TimeSpan filter to benchmark framerate instead. It seems more accurate.
Facinating! Amazing how much performance is impacted by data-binding. Thanks for sharing.
As I understand it, you are correct. You can bind to things in the code-behind as well as through the XAML and you should get the same performance benefit.
What I was doing previously was going into the code-behind and saying:
UIElement.x = datasource.x;
rather than taking the time to implement the INotifyProperty interface to handle my property changes.
I will say that, as a designer, I absolutely love the fact that WPF gives me the ability to handle everything I need to handle for the UI (including the application data) from the XAML so that I don’t get in the way of the developers. Because my blog is so designer centric, anything that is good for designers is going to get high praise from me. 🙂
That worries me a bit, or maybe I am misunderstanding something.
Does it mean that I must use XAML to have well performing apps? I thought that XAML is for ease of expressing the UI + data binding – not to exchange it. I was expecting that everything you can do in XAML you can do in code as well, without performance drop… Correct me if I am wrong.