Wpf:为什么 WriteableBitmap 变得越来越慢?

发布于 2024-08-29 16:39:58 字数 825 浏览 5 评论 0原文

有一个简单的 MSDN 示例关于 WriteableBitmap。

它演示了如何在按下鼠标并在 WPF 图像控件上移动时仅更新一个像素,从而用光标绘制手绘线。

 writeableBitmap.Lock();  
 (...set the writeableBitmap.BackBuffers pixel value...)
 writeableBitmap.AddDirtyRect(new Int32Rect(column, row, 1, 1));
 writeableBitmap.Unlock();

现在我试图理解快速移动鼠标指针时的以下行为:

如果图像/位图大小相对较小,例如 800:600 像素,则最后绘制的像素始终与鼠标指针位置“同步”,即鼠标移动没有延迟,反应非常快。

但如果位图变大,例如 1300:1050 像素,您会注意到延迟,最后绘制的像素总是在移动鼠标指针后面出现一点延迟。

因此,在这两种情况下,只有一个像素通过“AddDirtyRect”更新,反应速度应该与位图大小无关!?但当 Writeablebitmap 的大小变大时,它似乎会变慢。

或者,整个位图是否会在每次 writeableBitmap.Unlock(); 调用时以某种方式传输到图形设备,而不仅仅是在 AddDirtyRect 方法中指定的矩形区域?

弗里茨

There is a simple MSDN example about WriteableBitmap.

It shows how to draw a freehand line with the cursor by just updating one pixel when the mouse is pressed and is moving over a WPF -Image Control.

 writeableBitmap.Lock();  
 (...set the writeableBitmap.BackBuffers pixel value...)
 writeableBitmap.AddDirtyRect(new Int32Rect(column, row, 1, 1));
 writeableBitmap.Unlock();

Now I'm trying to understand the following behaviour when moving the mouse pointer very fast:

If the image/bitmap size is relatively small e.g. 800:600 pixel, then the last drawn pixel is always "synchronized" with the mouse pointers position, i.e. there is no delay, very fast reaction on mouse movements.

But if the bitmap gets larger e.g. 1300:1050 pixel, you can notice a delay, the last drawn pixel always appear a bit delayed behind the moving mouse pointer.

So as in both cases only one pixel gets updated with "AddDirtyRect", the reaction speed should be independent from the bitmap size!? But it seems that Writeablebitmap gets slower when it's size gets larger.

Or does the whole bitmap somehow get transferred to the graphic device on every writeableBitmap.Unlock(); call , and not only the rectangle area speficied in the AddDirtyRect method?

fritz

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

一袭水袖舞倾城 2024-09-05 16:39:58

.Net 3.5 中 WPF 的 WriteableBitmap 中存在一个错误,该错误会导致对 AddDirtyRect 的任何调用都会使整个图像无效,而不仅仅是矩形区域。

它应该已在 .Net 4.0 中修复,

请参阅 http://social.msdn.microsoft.com/Forums/en-US/wpfprerelease/thread/1b84e451-9698-431f-9c51-078825a729b5

There is a bug in WriteableBitmap for WPF in .Net 3.5 that causes any call to AddDirtyRect to invalidate the entire image, not just the rectangular region.

It is supposed to have been fixed in .Net 4.0

See http://social.msdn.microsoft.com/Forums/en-US/wpfprerelease/thread/1b84e451-9698-431f-9c51-078825a729b5

×纯※雪 2024-09-05 16:39:58

在 .Net 4 中,无论您在何处添加脏矩形,可写位图仍然会使整个区域无效。您可以使用 Perforator 来确认这一点,Perforator 是 Windows SDK v7.1 附带的 Windows Performance Toolkit 的一部分。

这是一个主要的性能错误。

In .Net 4, the writeable bitmap still invalidates the whole region no matter where you add a dirty rect. You can confirm this using Perforator, part of the Windows Performance Toolkit that comes with the Windows SDK v7.1.

This is a major performance bug.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文