Silverlight 4 中位图缓存的缺点是什么？
我们能够通过利用 Silverlight 的位图缓存来解决高 CPU 使用率问题，如下所述：
我们将 EnableGPUAcceleration 参数添加到
我发现了这个类似的问题，AnthonyWJones 给出了很好的答案：
因此，它的一个缺点是它使用更多的视频 RAM。我想这可能会让同时运行的其他图形密集型应用程序变得更糟。还有其他缺点吗？
如果显卡没有足够的视频 RAM 来缓存所有内容，我认为 Silverlight 会正常降级，并且只会使用更多的 CPU 周期来重新渲染 UI。
感谢您的帮助，
理查德
We were able to solve a high CPU usage problem by taking advantage of Silverlight's bitmap cache, as described here:
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 relying 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:
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在对位图缓存进行了大量实验之后，我们最终在应用程序中将其关闭。当您想要使用 GPU 对不发生变化的 UI 部分执行转换时，它效果很好 - 例如，如果您想要对一张图片进行动画、挤压、旋转等操作。但是位图如果您继续更新您想要缓存/操作的 UI 部分内的可视化树，缓存/GPU 加速（在其当前实现中）会显着减慢速度。如果您只是移动静态位图，那么缓存它并使用 GPU 加速它是有意义的。但很多时候，您可能会在 UI 中标记为缓存的部分中调整视觉树中的某个部分，如果发生这种情况，您需要每帧更新 GPU 的缓存，这非常慢、很慢、很慢。
换句话说，打开它是否有意义完全取决于您在哪里打开它以及您的应用程序正在做什么。因此，如果您正在使用位图缓存，或者您的 Silverlight UI 遇到性能问题，我强烈建议您（暂时）启用 缓存可视化 和 重绘区域。让你的应用程序在运行时看起来很时髦，但当你看到你的 UI 正在做什么消耗你所有的 CPU 时，它们就非常有价值了。
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.
我没有看到您所描述的问题，但我相信您可以过度使用位图缓存。
举例来说，您有一个 500x500 的“顶部”画布，其中包含 25 个“子”画布，每个画布都是 100x100。假设我们正在每个子画布中更新内容/颜色等。假设有一个事件会移动屏幕上的顶部画布。如果所有子画布以相同的间隔更改，则仅位图缓存顶部画布是有意义的。但是，如果子画布并非全部以相同的时间间隔更改，或者有时根本不更改，则在每个子画布上设置位图缓存可能会更有利。更进一步如果您位图缓存了顶部画布和每个子画布，则在缓存某些内容时可能会浪费周期，而没有任何好处。
或者我正在走一条与你所要求的完全不同的道路？
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?