Thanks to codeimp's comment on my previous post, I went back to my pixel-plotting test app to add-in a LockBits method to see how it would stand up to the pure GDI+ methods.
As it turns out, I found that a poorly-placed "End If" was causing the code to not draw 100,000 pixels per test ... but only 10,000 per test. Once I corrected that, I noticed that there was some time gaps starting to show between the methods. So, I jacked up the test amount to 1 million pixels per test and I added-in the LockBits approach as an 8th way to go about things.
On my ancient game dev laptop (1GHz P3), I got the following results (in seconds):
1 - DrawRectangle: 52.10
2 - FillRectangle: 42.90
3 - DrawEllipse: 59.34
4 - FillEllipse: 52.03
5 - DrawLine: 48.83
6 - DrawImage: 119.28
7 - DrawString: 79.32
8 - LockBits: 24.07
The relative speed of the LockBits is impressive. However, I was surprised that the DrawImage approach was the slowest way to go. And, FillRectangle looks to be the best of the standard GDI+ routines.
Now, keep in mind that these times are for 1 million plots, pausing every 1000 to invalidate the target PicBox and run a DoEvents to update the screen. In a normal game situation, you're likely to only need to draw a few thousand specks (at most) and you won't be pausing in the middle of it to make sure the screen updates.
There were a couple other asthetic things that I noticed as well. The Rect methods are incapable of drawing a true single pixel ... their definition forces both methods to draw a 2x2 square instead. Both Ellipse methods and the DrawLine method make 2-pixel long lines. This leaves the last 3 methods for being the only ones to give you true single pixels per plot.
LockBits comes out looking pretty good. The negative is that it takes a special bulk routine to make it efficient ... can't have each individual dot work as its own object that draws itself when requested. The GDI+ routines do allow for individual drawing at the expense of speed (and some asthetics).