I ran into an issue where my WPF application would consume about 20% of CPU time just sitting idle on a Page. A question from Tim Sneath led me to investigate an aspect of the app that uses the CompositionTarget.Rendering callback to do some animations that can’t be done in other ways in WPF right now.
I had several UIElements that each had the Rendering event hooked up, and the code in the event handler would do next to nothing most of the time, since the animation only was kicked off on a mouse up event. I modified the code, so that the event hookup doesn’t happen until the mouse up event comes in, and also so that an unhook happens when the animation is finished. This promptly took down the CPU load to the typical intermittent 1-2%.
Thanks for reading! It looks like you're new here. Welcome! If you like what you see, I encourage you to subscribe to my RSS feed. If you're worried about adding another RSS feed that will add to your information overload, don't! I'm not a prolific poster. Thanks for visiting!
Like this:
Like Loading...
Categories: WPF
2 Comments »
2 Responses to “CompositionTarget.Rendering can be a CPU hog”
[…] By using CompositionTarget, you can do stuffs like this but don’t over-do it cause it’s expensive in performance. CompositionTarget.Rendering is an alternate way to get high fidelity (animation class) rendering. […]
[…] once to get more in-depth training on WPF and Vista, and once to get help with troubleshooting performance issues we had run into. That’s when I learned that there is such a thing as a “managed memory […]
Care to comment?