Fast drawing lots of rectangles one at a time in WPF
Using a WriteableBitmap will be the fastest approach. For testing you could pre-allocate an array and use a Stopwatch to sample timings as you go about rendering, you can then analyse the timings to get some idea of performance.
One overriding issue you have is with garbage collection. This will unfortunately introduce potential for the exact kind of performance issues you describe i.e. occasional stalling whilst GC is carried out. You could experiment with low latency GC to mitigate this.
Update
Here is an example of using low latency GC:
http://blogs.microsoft.co.il/blogs/sasha/archive/2008/08/10/low-latency-gc-in-net-3-5.aspx
You could leverage this to ensure that there are no garbage collections during your "dead time" i.e. rendering time.
Update 2
As I mentioned in my comment a while ago - are you batching updates to your WritableBitmap?
Your device update frequency is too high to able to sustain writing to the bitmap for each device update - I think there are 10k-100k updates per second. Try and update your bitmap on a more sensible frequency (e.g. 60 or 25 times per second), as the overhead of forcing a bitmap render will dominate performance at 10k-100k updates per second. Write to a buffer when you receive device updates, then periodically transfer this buffer to the WritableBitmap. You could use a timer for this, or do it every n device updates. In this way you will batch your updates and vastly reduce WritableBitmap render overhead.
Update 3
Ok, it sounds like you are updating the WritableBitmap 10k-100k times per second - this isn't feasible. Please try a frame\batch based mechanism as described previously. Also your display is only likely to be updated at 60 frames per second.
If you are concerned about blocking your device updates, then consider using two alternating back buffers and multi-threading. In this way you periodically switch which back buffer your device writes to, and use a second thread to render the swapped buffer to the WritableBitmap. As long as you can swap the buffer in < 10µs, you can do this in the dead time without blocking your device updates.
Update 4
Further to a response to my question, it would appear that there is currently a "lock\unlock" being called for each of the 100k updates per second. This is what is likely killing performance. On my (high-powered) system I measured 100k "lock\unlock" at ~275ms. That's pretty heavy and will be much worse on a lower powered system.
This is why I think 100k updates per second is not achievable i.e. lock -> update -> unlock. The locking is just too expensive.
You need to find a way of bringing the number of locking calls down by either not locking at all, locking every n operations, or perhaps batching requests and then applying the batched update in a lock. There's a few options here.
If you go for a batched update, it could be as small as 10 cycles, which would bring your update frequency down to 10k updates per second. This would reduce your locking overhead by a factor of 10.
Example benchmark code for locking overhead on 100k calls:
lock/unlock - Interval:1 - :289.47ms
lock/unlock - Interval:1 - :287.43ms
lock/unlock - Interval:1 - :288.74ms
lock/unlock - Interval:1 - :286.48ms
lock/unlock - Interval:1 - :286.36ms
lock/unlock - Interval:10 - :29.12ms
lock/unlock - Interval:10 - :29.01ms
lock/unlock - Interval:10 - :28.80ms
lock/unlock - Interval:10 - :29.35ms
lock/unlock - Interval:10 - :29.00ms
Code:
public void MeasureLockUnlockOverhead()
{
const int TestIterations = 5;
Action<string, Func<double>> test = (name, action) =>
{
for (int i = 0; i < TestIterations; i++)
{
Console.WriteLine("{0}:{1:F2}ms", name, action());
}
};
Action<int> lockUnlock = interval =>
{
WriteableBitmap bitmap =
new WriteableBitmap(100, 100, 96d, 96d, PixelFormats.Bgr32, null);
int counter = 0;
Action t1 = () =>
{
if (++counter % interval == 0)
{
bitmap.Lock();
bitmap.Unlock();
}
};
string title = string.Format("lock/unlock - Interval:{0} -", interval);
test(title, () => TimeTest(t1));
};
lockUnlock(1);
lockUnlock(10);
}
[SuppressMessage("Microsoft.Reliability",
"CA2001:AvoidCallingProblematicMethods", MessageId = "System.GC.Collect")]
private static double TimeTest(Action action)
{
const int Iterations = 100 * 1000;
Action gc = () =>
{
GC.Collect();
GC.WaitForFullGCComplete();
};
Action empty = () => { };
Stopwatch stopwatch1 = Stopwatch.StartNew();
for (int j = 0; j < Iterations; j++)
{
empty();
}
double loopElapsed = stopwatch1.Elapsed.TotalMilliseconds;
gc();
action(); //JIT
action(); //Optimize
Stopwatch stopwatch2 = Stopwatch.StartNew();
for (int j = 0; j < Iterations; j++)
{
action();
}
gc();
double testElapsed = stopwatch2.Elapsed.TotalMilliseconds;
return (testElapsed - loopElapsed);
}
Full Disclosure: I have contributed to the WriteableBitmapEx open source project, however it is not my library nor am I affiliated with its owner
To add to the excellent answer by chibacity, I would suggest looking at the WriteableBitmapEx library. This is an excellent WPF, Silverlight and Windows Phone library which adds GDI-like drawing extension methods (blitting, lines, shapes, transforms as well as batch operations) to the WriteableBitmap class.
The latest version of WBEx contains a refactor that I carried out to allow batch operations. The WriteableBitmapEx library now has an extension method called GetBitmapContext(), to return an IDisposable struct which wraps a single lock/unlock/invalidate block. With the following syntax you can easily batch your drawing calls and perform only one Lock/Unlock/Invalidate at the end
// Constructor of BitmapContext locks the bmp and gets a pointer to bitmap
using (var bitmapContext = writeableBitmap.GetBitmapContext())
{
// Perform multiple drawing calls (pseudocode)
writebleBitmap.DrawLine(...)
writebleBitmap.DrawRectangle(...)
// etc ...
} // On dispose of bitmapcontext, it unlocks and invalidates the bmp