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

Intricacy

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

Fachini

But I see that someone in that thread was still experiencing perf probs, so has anyone truly confirmed it is fixed? – Evanston

As of now it appears WriteableBitmap still has performance issues. I use AddDirtyRect like fritz to change only the pixels needing changed, but the bigger the image, the slower it gets. I am using .NET 4.6, by the way :/. – License

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.

Havener