Wpf: Why is WriteableBitmap getting slower?

Question

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

Answer 1

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

Answer 2

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.