In this post, I’m going to talk about two key API’s for performance in WPF. These are RenderCapability.Tier and Storyboard.DesiredFrameRate. In this post, I’m going to show:
- How to leverage RenderCapability.Tier to scale your app up or down.
- How to use RenderCapability.Tier in markup.
- How to apply DesiredFrameRate to reduce CPU consumption.
For the machine on which it’s run, RenderCapability.Tier signals the machine’s hardware capabilities. Tier=0 means software rendering; Tier=2 is hardware rendering (for those features that can be rendered in hardware); Tier=1 is a middle ground (some things in hardware and some in software.) You can probably see how this might be useful to scale up or down the richness of an application depending on the hardware.
(Note: RenderCapability.Tier is an integer value using the high word to indicate the tier. You’ll need to shift by 16 bits to get the corresponding tier values. Adam Smith posts about why this was chosen.)
The second API I mentioned was Storyboard.DesiredFrameRate (DFR.) DFR allows you to specify, manually, what the frame rate “should” be (the animation system attempts to get as close as possible to the DFR value but there are no guarantees.) By default, WPF attempts 60 fps. The up side to this is that animations look better; the down side is that you may not need 60 fps but you may be spending the extra CPU cycles.
Putting Them Together
You can use RenderCapability.Tier in markup with a small helper class. The trick is to wrap up the property in a DependencyProperty. From there, the property can be used to set DFR. Below, you’ll find both the code for the RenderCapability.Tier, how to use it in markup and how to set DesiredFrameRate. I picked different DFR values for the different Tiers. The resulting UI isn’t that exciting (a spinning Button) but it demonstrates the concept.