Fast image pixel access with GDI+ and .net

I have yet again hit a brick wall with regards to speed in processing dynamic images server side using System.Drawing in  As I have covered in a previous article regarding image cropping I have had difficulty in the past finding a quick way to access each individual pixel of an image.  Unfortunately my algorithm was only the result of a having to deal with a slow getpixel method.  Using what I had at the time that was the best I could come up with.

Enter and a wealth of additional capability.  I came across a great set of articles from One  great article in particular pertained to my issue exactly.  Direct memory access to pixel data using lock bits.  Here is a direct link.  It is not often that I find exactly what I need, but this was perfect.

Here is a snippet of Bob’s code, I also added some lines to elaborate where you can access the other 3 components of the image data Bob’s code did not illustrate.

     BitmapData bmd=bm.LockBits(new Rectangle(0, 0, 10, 10), System.Drawing.Imaging.ImageLockMode.ReadOnly, bm.PixelFormat);
      int PixelSize=4;
      for(int y=0; y< bmd.height; y++)
        byte* row=(byte *)bmd.Scan0+(y*bmd.Stride);
        for(int x=0; x< bmd.width ; x++>
          row[x*PixelSize]=255; //blue component
          row[(x*PixelSize)+1] = 255; // green component
          row[(x*PixelSize)+2] = 255; // red component
          row[(x*PixelSize)+3] = 255; // alpha component

So what is the advantage of this? One word SPEED. You can accomplish the same thing (reading,writing) pixel data using the managed code in system.drawing (getpixel() ), but you will find very quickly if you are doing any serious processing it is very slow.  This method is far superior assuming you know the risk (you can potentially mess with memory you aren’t supposed to).  I’m happy to report I have an efficient cropping function now that appears will speed up alot of code already in use.

Slow javascript performance in IE (string concatenation)

I’ve come to realize while IE 7 is no less than a landslide improvement over IE 6, it is still IE. While IE alone in the market appeared to be a superior product, compared to the likes of firefox it is simply inferior. Firefox script interpreter is all around faster, in my experience it is not just 2-5x faster, it can be 100x for some operations. Crazy right? I’ve been pushing the envelope with an ajax/dojo based site I’ve spent a large amount of time on. To be blunt there is more than one occasion during the development process I have had to rewrite code to accomadate the script execution of IE 7. Looking back most of the time the script was poorly thought out set of operations that needed to be rewritten anyway.

My last road block however was a particular chunk of JSON data that was packaged up base64 encoded then sent off to the server via the dojo xhrpost method. I really was scratching my head whenever I was in IE and got up to a 3-10 second delay while sending this data to the server. While in Firefox and Safari there was none. After a period of a few hours I narrowed the delay to my base64 encoding script running on the client side causing the delay. It didn’t take long start finding that IE is incredibly inefficient as string concatenation. The solution is simple.  Implement a string buffer.  I have provided some snippets along with the corrected JS file for viewing.

// addresses some speed issues with IE 
function StringBuffer()
this.buffer = [];
StringBuffer.prototype.append = function append(string) {
return this;
StringBuffer.prototype.toString = function toString() {
return this.buffer.join("");
// end buffer
function encodeBase64(str){
var buf = new StringBuffer(); // new buffer code
//result += (base64Chars [(( inBuffer[0] &lt;&lt; 4 ) &amp; 0x30) | (inBuffer[1] &gt;&gt; 4) ]);
buf.append(base64Chars [(( inBuffer[0] &lt;&lt; 4 ) &amp; 0x30) | (inBuffer[1] &gt;&gt; 4) ]);

Source for the entire base64 file here:

Diagnose ‘File does not exist’ error in

I have ventured deep into the land of the past few months.  Luckily the the blogsphere keeps me on track.  Every day or so I run into a nagging issue with or something I can’t quite accomplish.  I have been nearing the end of my project and have simply had a bug which I could not fix.  It seems will fire an error when ANY file is missing on an webpage.  This is incredibly difficult to diagnose since the error does not contain the file that is missing!  See below for an example

MESSAGE: File does not exist.
SOURCE: System.Web
QUERYSTRING: 695777780
TARGETSITE: Void ProcessRequestInternal(System.Web.HttpContext)
STACKTRACE: at System.Web.StaticFileHandler.ProcessRequestInternal(HttpContext context)…

Catching the error is accomplished by hooking into the Application_Error event typically in the global.asax

void application_Error(object sender, EventArgs e)


K# offered a great post on just how he went about solving this issue. Basically setting a breakpoint at the above section of code to see the error when it happens. That isn’t quite enough, you’ll notice visually studio even in the watched variables has nothing that leads to the missing file. If you add a watch to ((HttpApplication)sender).Context.Request you will quickly see the exact file causing the error message.

My ultimate solution was to add the ((HttpApplication)sender).Context.Request.FilePath in all my global error logging so the file that is missing is always included in the error message.