Click here to Skip to main content
15,170,971 members
Articles / Multimedia / GDI+
Posted 19 Mar 2010

Tagged as


41 bookmarked

Rendering fast with GDI+ - What to do and what not to do!

Rate me:
Please Sign up or sign in to vote.
4.95/5 (28 votes)
28 Mar 2010CPOL3 min read
Everyone knows GDI+ is generally slow in rendering, what is not so obvious is what combination of settings is the fastest.I have an app which renders a lot of items, which may be drawn or are bitmap-sourced 'sprites', onto a full page (usually 1024x768). The first attempts ran at around 3...
Everyone knows GDI+ is generally slow in rendering, what is not so obvious is what combination of settings is the fastest.

I have an app which renders a lot of items, which may be drawn or are bitmap-sourced 'sprites', onto a full page (usually 1024x768). The first attempts ran at around 3 frames/sec - with the speedups noted here I got the rate upto 41fps.

My application roughly does the following:

load a background Bitmap: bgndBitmap
load any Bitmaps used for 'sprites': spriteBitmap
create a Bitmap to render into: renderBitmap
create a Graphics object to draw on the Bitmap
while( forever )
     draw bgndBitmap
     for( all items... )
         draw part of spriteBitmap

     draw the renderBitmap into a dialog

What to do
Always use PixelFormat32bppPARGB

That's pre-multiplied Alpha, even though the particular image or Bitmap may not have any Alpha.

Since the user of my app can use several formats for a background (including .png), then just loading the image using...

Bitmap *LoadABitmap( char *filename )
    WCHAR wname[1024];
    MultiByteToWideChar( CP_ACP, 0, filename, -1, wname, 1000 );
    Bitmap *loadBmp= new Bitmap( wname, FALSE );
    if( loadBmp->GetLastStatus() == Ok )

...could result in one of several formats.
What we want is a 'solid' background in a known format, so I redraw the loaded bitmap into a new bitmap with a fixed format.

PixelFormat32bppRGB would seem appropriate as this would remove any alpha (tranparency) component which might be present - however, this will not result in the fastest rendering.

What we want is PixelFormatPARGB with all the Alpha set to 'solid'.
In my case I just:

Bitmap *newBmp= new Bitmap( loadBmp->GetWidth(), loadBmp->GetHeight(),
                           PixelFormat32bppPARGB );
Graphics *pGraphics= new Graphics( newBmp );

pGraphics->Clear( 0xffffffff );  // clear to solid white

Rect sizeR( 0,0,loadBmp->GetWidth(), loadBmp->GetHeight());
pGraphics->DrawImage( loadBmp, sizeR, 0,0,
                         UnitPixel );
delete pGraphics;
delete loadBmp;

return newBmp;

More generally, you could draw the loaded bitmap into an RGB bitmap and then draw the RGB bitmap into a PARGB bitmap.

I do the same sort of thing for the sprite bitmaps, but here I want to preserve any transparency - just get the format to be 'PARGB'.

Set the Graphics options

The following settings are generally the fastest:

Graphics *pGraphics= Graphics::FromHWND( hwndMyPictureWindow, FALSE );

pGraphics->SetCompositingMode( CompositingModeSourceCopy );
pGraphics->SetCompositingQuality( CompositingQualityHighSpeed );
pGraphics->SetPixelOffsetMode( PixelOffsetModeNone );
pGraphics->SetSmoothingMode( SmoothingModeNone );
pGraphics->SetInterpolationMode( InterpolationModeDefault );

pGraphics->DrawImage( RenderBitmap, 0, 0 );
delete pOutputGraphics;

Use these settings for 'blitting' bitmaps at 1:1 scale, as in the above example we're simply copying the bitmap to the output window.

However, the results will be somewhat disappointing if you are doing any scaling, rendering of sprites or text.

For drawing sprites and such, these settings are good quality and reasonably fast:

pGraphics->SetCompositingMode( CompositingModeSourceOver );  // 'Over for tranparency
pGraphics->SetCompositingQuality( CompositingQualityHighSpeed );
pGraphics->SetPixelOffsetMode( PixelOffsetModeHighSpeed );
pGraphics->SetSmoothingMode( SmoothingModeHighSpeed );
pGraphics->SetInterpolationMode( InterpolationModeHighQuality );

Do NOT think that, for example, InterpolationModeLowQuality should be faster... it isn't (don't ask me why!).

The fastest settings for drawing sprites with transparency, if you can handle some edge effects, are:

pGraphics->SetCompositingMode( CompositingModeSourceOver );
pGraphics->SetCompositingQuality( CompositingQualityHighSpeed );
pGraphics->SetSmoothingMode( SmoothingModeNone );
pGraphics->SetPixelOffsetMode( PixelOffsetModeHalf );
pGraphics->SetInterpolationMode( InterpolationModeNearestNeighbor );

Some of these settings are interrelated, InterpolationModeNearestNeighbor is only the fastest if you have PixelOffsetModeHalf also set.

Just a word of caution: PixelOffsetModeHalf does have some other effects - GetVisibleClipBounds() will return {1,1,X,Y} rather than {0,0,X,Y}, which will cause LockBits() to fail.

For scaling one whole bitmap into another, I use:

// set quality for scaling
pGraphics->SetCompositingMode( CompositingModeSourceCopy );
pGraphics->SetCompositingQuality( CompositingQualityHighSpeed );
pGraphics->SetPixelOffsetMode( PixelOffsetModeHighSpeed );
pGraphics->SetSmoothingMode( SmoothingModeHighSpeed );
pDestGraphics->SetInterpolationMode( InterpolationModeHighQuality );

if( g_RenderFastest )  // global flag to render fastest, but reduce quality
    pGraphics->SetInterpolationMode( InterpolationModeDefault );
    pGraphics->SetSmoothingMode( SmoothingModeNone );
    pGraphics->SetPixelOffsetMode( PixelOffsetModeHalf );

For completeness, here's what I set for drawing text with DrawString():

pGraphics->SetCompositingMode( CompositingModeSourceOver );
pGraphics->SetCompositingQuality( CompositingQualityHighSpeed );
pGraphics->SetInterpolationMode( InterpolationModeHighQuality );
pGraphics->SetPixelOffsetMode( PixelOffsetModeHighSpeed );
pGraphics->SetSmoothingMode( SmoothingModeNone );
// Note: TextRenderingHintClearTypeGridFit looks real crap
//       if we're drawing onto a transparent object
//       but now we're not... anyhow, this is OK:
pToGraphics->SetTextRenderingHint( TextRenderingHintAntiAliasGridFit );

What not to do

Don't mix bitmap formats

Rendering an ARGB bitmap onto an RGB bitmap can be slower by more than a factor of 10 compared to two PARGB bitmaps. Generally, it seems that ARGB always causes GDI+ to internally do a load of pre-multiplying and eats the CPU.

Don't even think about threads

I mention this 'cos I tried... (my app actually needs to output to 4 monitors on a single machine) the code worked fine, but GDI+ is not designed for multithreading and at best, if you get the CRITICAL_SECTION's right, almost renders sequentially anyway.

See the notes in MSDN under GDI+ Security Considerations, it's right there at the end (in a locked filing cabinet marked "Beware of the leopard").


The options available are not obvious, so if you're doing some investigation, you must profile your code to see what effect each of 'em has. Guessing doesn't work, what may sound like a faster/less quality option probably isn't.

The End

That's the lot, hope it's of some use to someone.

Tony Wilk

[mail at tonywilk dot co dot uk]

The End.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

United Kingdom United Kingdom
Developer in just about anything from 6502 machine code thru C, C++ and now things like PHP and javascript. Used to develop hardware and still dabble with electronics and ham radio when I'm not letting off pyrotechnics, shooting or flying my VPM M16 gyroplane.

Comments and Discussions

Questionextremely useful Pin
marktopinka31-May-17 12:50
Membermarktopinka31-May-17 12:50 
QuestionThanks Tony! Very interesting fellow! Pin
shooky566-Jan-15 8:23
Membershooky566-Jan-15 8:23 
AnswerRe: Thanks Tony! Very interesting fellow! Pin
tonywilk11-Mar-15 7:21
professionaltonywilk11-Mar-15 7:21 
GeneralMy vote of 5 Pin
YoungShall5-Jul-13 0:36
MemberYoungShall5-Jul-13 0:36 
GeneralMy vote of 5 Pin
Ha Viet23-Nov-12 4:32
MemberHa Viet23-Nov-12 4:32 
GeneralMy vote of 5 Pin
nv38-Jul-12 22:17
Membernv38-Jul-12 22:17 
GeneralReason for my vote of 5 Great tip, deserve full point Pin
ThatsAlok16-Aug-11 4:14
MemberThatsAlok16-Aug-11 4:14 
GeneralGreat! useful tip! Pin
ThatsAlok16-Aug-11 4:14
MemberThatsAlok16-Aug-11 4:14 
GeneralReason for my vote of 5 very usefull Pin
fisker.cui10-Aug-11 9:23
Memberfisker.cui10-Aug-11 9:23 
GeneralReason for my vote of 5 good research and testing of the sub... Pin
Trethbos9-Jul-10 1:12
MemberTrethbos9-Jul-10 1:12 
GeneralUsing a PARGB format helped me a lot! It's anything but obvi... Pin
joerg-smn29-Jun-10 3:24
Memberjoerg-smn29-Jun-10 3:24 
GeneralGLGDI+ Pin
dmbreaker12-Sep-10 11:48
Memberdmbreaker12-Sep-10 11:48 
QuestionIsn't it simpler to use Bitmap::Clone to convert Bitmap to another format? Pin
__stas__13-Jul-10 4:21
Member__stas__13-Jul-10 4:21 
AnswerRe: Isn't it simpler to use Bitmap::Clone to convert Bitmap to another format? Pin
tonywilk13-Jul-10 7:36
professionaltonywilk13-Jul-10 7:36 
GeneralPrint server Configuration help Pin
Sivaprasad S Nair31-Mar-10 5:46
MemberSivaprasad S Nair31-Mar-10 5:46 
Generalvery interesting Pin
Luc Pattyn28-Mar-10 19:08
sitebuilderLuc Pattyn28-Mar-10 19:08 
GeneralRe: very interesting - A speed comparison Pin
tonywilk29-Mar-10 5:41
professionaltonywilk29-Mar-10 5:41 
Ok... a comparison:

I've just run up my app with a page which has a 1024x768 bitmap as the background on top of which is rendered 40 sprites from another bitmap. The sprites are 64x128 pixels, scaled onto the background at around 32x100. There's another 14 sprites which are 64x64 scaled to 32x32 and about 30 large buttons drawn with GDI+ FillRectangle and FillPolygon's for the edge bevels plus some DrawString text.

The app draws the background onto a 1024x768 bitmap, draws all the items then draws the resulting Bitmap to the dialog using a Graphics::FromHWND( frame_in_the_dialog ).
For this test I set the output window at 1024x768.
My machine is a slightly aging HP Compaq dc7600 with a 3.4GHz Pentium D CPU

This lot averages 17.9mS to draw and leaving to to run flat out (I usually limit
the framerate in this app to 12fps), it gets 52.4fps.
Task manager shows CPU usage at 51% - eating all of 'one processor'.

Just altering the PixelFormat of the render bitmap and/or the sprite bitmaps:
All bitmaps PARGB:       17.8mS   52.4fps
RenderBitmap as RGB:     21.9mS   41.3fps   not a lot of difference with destination as RGB
Sprite bmps as ARGB:    331.0mS    2.9fls   wow, what a difference a 'P' makes! 
Dest:RGB+Sprites ARGB:  460.0mS    2.1fps

From 2.1fps to 52.4fps is about 25 times faster, and that's leaving all the Graphics settings alone.

The above was done with my 'still good looking' Graphics settings, switching to quality smoothing for the sprites it still manages 29.8mS/31.4fps

Tony Wilk
modified on Monday, March 29, 2010 10:48 AM

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

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