What's the downside of bitmap caching in Silverlight 4?

We were able to solve a high CPU usage problem by taking advantage of Silverlight's bitmap cache, as described here:

• Silverlight 3 and GPU Acceleration
• Discovering Silverlight 3 – Deep Dive into GPU Acceleration

We added the EnableGPUAcceleration parameter to the <object> tag. To bring the CPU usage down to a reasonable level, we had to add CacheMode="BitmapCache" to the root visual grid for the whole app. So I'm wondering if there's any downside to re开发者_如何转开发lying so much on the bitmap cache. If it was always beneficial, I assume it would be enabled by default.

I found this similar question with a good answer by AnthonyWJones:

• Any reason not to check “application library caching” and “GPU acceleration” in silverlight apps?

So one downside is that it uses more video RAM. I guess this could make things worse for other graphics-intensive apps running at the same time. Are there any other downsides?

If the graphics card doesn't have enough video RAM to cache everything, I assume Silverlight will degrade gracefully and will just use more CPU cycles to re-render the UI.

Thanks for your help,

Richard

---

After experimenting a great deal with bitmap caching, we ended up turning it off in our application. It works well when you're wanting to use the GPU to execute transforms on a piece of your UI that isn't changing -- for instance, if you have a picture that you want to animate, squish, rotate, etc. But bitmap caching/GPU acceleration (in its current implementation) slows things down pretty dramatically if you're continuing to update the visual tree inside the part of your UI that you'd like to cache/manipulate. If you're just moving around a static bitmap, it makes sense to cache it and use the GPU to accelerate it. But quite often, you might be tweaking pieces somewhere down the visual tree from the piece of your UI that you flagged to cache, and if that's happening, you need to update the GPU's cache each frame, and that's slow, slow, slow.

In other words, whether it makes sense for you to turn it on or not depends entirely on where you turn it on, and what your application is doing. Because of this, my strong recommendation, if you're using bitmap caching, or if you're experiencing performance problems with your Silverlight UI, is to (temporarily) enable cache visualization and redraw regions. Makes your app look funky as hell when they're on, but they're invaluable when it comes to seeing what your UI is doing that's chewing up all your CPU.

---

I don't see concerns in what you described, but I believe you can over use bitmap caching.

Say for instance you had a 500x500 'top' canvas, and it contained 25 'sub' canvases each 100x100. Lets say we were updating content/colors, etc.. in each of the sub canvases. Lets say there was an event that would move the top canvas on the screen. If all the sub canvases changed at the same interval, it would make sense to only bitmap cache the top canvas. However, if the sub canvases did not all change at the same interval, or sometimes not at all, it could turn out to be more benefitial to set bitmap caching on each sub canvas instead. Taking this one step further If you bitmap cached both the top and each sub canvas, there could be wasted cycles in caching something with no benefit.

Or am I going down a completely different path than what you are asking?