Click here to Skip to main content
Click here to Skip to main content
Go to top

Fast Drawing of Non-32bpp Images with System.Drawing

, 5 Jun 2007
Rate this:
Please Sign up or sign in to vote.
Avoid the unnecessary pixel format conversion that normally happens when drawing a portion of an image to the screen with System.Drawing

Introduction

It is a well-known fact that when drawing images to the screen that are a different pixel format than the screen's pixel format, format conversion must be performed. GDI+ provides the CachedBitmap class to facilitate easy caching of a converted version of a bitmap. However, this functionality is not exposed in .NET, so normally bitmaps that do not match the screen format are converted on each drawing call.

The project

At first glance, it would seem that it shouldn't be too performance-degrading, even for large images, to just draw the area of the bitmap that is exposed or invalidated using Graphics.DrawImage(). However, a further performance examination reveals that the speed of Graphics.DrawImage() is always related to the size of the whole bitmap, not the size of the area being drawn. If you tell GDI+ to draw even a 1-pixel-by-1-pixel section of a bitmap that is not in the same pixel format as the screen, it will convert the entire bitmap to the screen pixel format before completing the drawing call!

This is clearly unacceptable, especially since digital camera images are typically 24bpp. So, I set out to write a routine that would create a new bitmap that is the size of the area that needs to be drawn. It would then copy the correct section of the source bitmap into that area and draw that to the screen. This would give much better performance.

However, I also wanted to see if I could make GDI+ convert only the relevant area of the bitmap directly, rather than having the overhead of the extra copying routine. I realized that with my EditableBitmap class, I could create an EditableBitmap as a view on another EditableBitmap's bits. Then I could just report to GDI+ that the "stride" is the size of the source bitmap's stride. So, there would be a distinct GDI+ bitmap information class that GDI+ could work with, but there would not be any more memory overhead related to the bits for an extra bitmap. There would also not be a performance reduction, however minor, associated with copying bits over to a copied bitmap section with each drawing call. I added a method called CreateView(), which took a rectangle that specified the bounds of the view:

public EditableBitmap CreateView(Rectangle viewArea)
{
    if(disposed)
        throw new ObjectDisposedException("this");
    return new EditableBitmap(this, viewArea);
}

It delegates the "magic" to a protected constructor:

protected EditableBitmap(EditableBitmap source, Rectangle viewArea)
{
    owner=source;
    pixelFormatSize=source.pixelFormatSize;
    byteArray=source.byteArray;
    byteArray.AddReference();
    stride = source.stride;
    
    try
    {
        startOffset=source.startOffset+(stride*viewArea.Y)+
            (viewArea.X*pixelFormatSize);
        bitmap = new Bitmap(viewArea.Width, viewArea.Height, 
            stride, source.Bitmap.PixelFormat, 
            (IntPtr)(((int)byteArray.bitPtr)+startOffset));
    }
    finally
    {   
        if(bitmap==null)
            byteArray.ReleaseReference();
    }
}

The constructor copies all of the properties from the source bitmap that will be the same. It stores a reference to the bitmap that it is a view on in the Owner property. It then calculates a byte offset from the start of the owner's byte array to the first pixel of the view bitmap. It then creates a GDI+ Bitmap object, passing in the offset byte pointer and the view's width and height. So far, so good! We have a bitmap object that tricks GDI+ into thinking that it is a standalone bitmap, when it really points to part of a larger bitmap.

However, we still have to worry about those pesky resource management issues. The EditableBitmap class depends on a pinned byte array to store the pixel data. With bitmap views, that byte array is shared between multiple bitmaps. We want the views to still be operational when the root bitmap is disposed and definitely vice versa, as well. So, we have to make it so that the bit array is only destroyed when there are no more EditableBitmap instances that use it. To do this, I added a new class, SharedPinnedByteArray, that manages the byte array and keeps a reference count. When the reference count reaches zero or it is finalized, it unpins the byte array.

The end result is a much faster rendering time for large, non-screen-format bitmaps. The demo included demonstrates the speed difference. When you run it, it will ask you to choose a bitmap using a file dialog. Choose a large bitmap. Try scrolling around, especially dragging the scrollbar thumbs. You will most likely see "tearing:" areas that paint slowly enough that you can easily see the missing area. Now click on the bitmap display area so that the title bar of the form says "New Method." Try scrolling again and it should be very smooth.

History

  • 5 June, 2007 -- Article edited and posted to the main CodeProject.com article base
  • 15 November, 2006 -- Original version posted

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Share

About the Author

J. Dunlap
Web Developer
United States United States
My main goal as a developer is to improve the way software is designed, and how it interacts with the user. I like designing software best, but I also like coding and documentation. I especially like to work with user interfaces and graphics.
 
I have extensive knowledge of the .NET Framework, and like to delve into its internals. I specialize in working with VG.net and MyXaml. I also like to work with ASP.NET, AJAX, and DHTML.

Comments and Discussions

 
QuestionUse EditableBitmap in Visual Basic 2010 Pinmemberh. de boer16-Oct-11 9:50 
GeneralRotation [modified] PinmemberScalee1-Feb-10 10:45 
GeneralRe: Rotation PinmemberScalee2-Feb-10 12:25 
GeneralDrawImageUnscaled(Bitmap, Point) PinmemberMartijn van Dorp20-Jul-09 6:39 
GeneralCloning Pinmemberswight9-Apr-09 15:20 
GeneralRe: Cloning PinmemberJ. Dunlap16-Apr-09 8:50 
GeneralRe: Cloning Pinmemberswight19-Apr-09 14:45 
GeneralBig thanks! PinmemberFroggr8-Apr-09 5:15 
Questionmain image and regions of interest PinmemberAl_S26-Feb-09 2:32 
AnswerRe: main image and regions of interest PinmemberFroggr8-Apr-09 5:00 
GeneralRe: main image and regions of interest PinmemberAl_S8-Apr-09 5:04 
GeneralUsed your EditableBitmap class in my codeproject PinmemberBerend Engelbrecht29-Jun-08 23:34 
QuestionRe: Used your EditableBitmap class in my codeproject PinmemberAl_S26-Feb-09 3:01 
AnswerRe: Used your EditableBitmap class in my codeproject PinmemberBerend Engelbrecht26-Feb-09 6:59 
QuestionRe: Used your EditableBitmap class in my codeproject PinmemberAl_S26-Feb-09 8:07 
AnswerRe: Used your EditableBitmap class in my codeproject PinmemberBerend Engelbrecht26-Feb-09 9:07 
GeneralRe: Used your EditableBitmap class in my codeproject PinmemberAl_S26-Feb-09 9:27 
Generalexercises in c# PinmemberMr.PoorEnglish9-Jan-08 10:40 
GeneralGood work, but... PinmemberAdam Byrne16-Nov-06 5:36 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web04 | 2.8.140905.1 | Last Updated 5 Jun 2007
Article Copyright 2006 by J. Dunlap
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid