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

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,
                         (int)loadBmp->GetWidth(),
                         (int)loadBmp->GetHeight(),
                         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 );

Note:
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").


Guess...

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.

Yours,
Tony Wilk

[mail at tonywilk dot co dot uk]













The End.