Loading JPG & PNG resources using GDI+

• Download demo project - 121 Kb
• Download source - 1 Kb

Introduction

Recently, I needed to display some JPG and PNG files. I had an old copy of LeadTools and the open source libraries for both formats, but wanted my executable to be as small as possible. So I decided to give GDI+ a try. I quickly found GDI+ to be poorly designed and very quirky, but it worked well for my purposes until I discovered, to my horror, that GDI+ cannot load JPG or PNG images stored as resources!

Like, I'm sure, other developers facing this issue, I disbelieved the documentation and tried Bitmap::FromResource to no avail. While perusing the Bitmap methods available, I ran across Bitmap::FromStream.

After a bit of testing and several errors, due mostly to the horrible GDI+ documentation, I came up with working code. After a night of rest, I decided to encapsulate the code in a simple class to ensure memory got freed. The result were two classes: CGdiPlusBitmap and CGdiPlusBitmapResource.

The Gotcha

Before discussing the code itself, there is a caveat with GDI+ that must be addressed. With JPG, some TIFF and other formats, the original image information must be available at all times. In other words, if you open a bitmap using Bitmap::FromFile, you cannot delete or otherwise change that file while the image is open. This same restriction applies to CGdiPlusBitmapResource. (My testing found that PNG and BMP files don't seem to follow this generalization, though I don't know if this is standard behavior or just a fluke with my file set.)

GDI+ Initialization

GDI+ needs to be initialized before any GDI+ calls are made. I suggest adding the following data member to the class derived from CWinApp:

ULONG_PTR m_gdiplusToken;

In InitInstance(), add the following calls:

Gdiplus::GdiplusStartupInput gdiplusStartupInput;
Gdiplus::GdiplusStartup(&m_gdiplusToken, &gdiplusStartupInput, NULL);

In ExitInstance(), add the following:

Gdiplus::GdiplusShutdown(m_gdiplusToken);

The Class

I created two classes, with the base class being a very simple encapsulation of Bitmap and the derived class encapsulating the global memory. I suppose that if I ever had the patience and desire, I could extend that class, but I have no need to do so. (If you're curious why I didn't simply derive from the ATL class CImage, it's because the code was used in a program that didn't use MFC or ATL. However, the code is so simple, it could easily be modified to use CImage as the base class.)

I'm not going to bother going over the CGdiPlusBitmap class except to say that it has a single, public, data member Bitmap* m_pBitmap. (In the class I prefaced the GDI+ objects with the Gdiplus namespace in case the developer doesn't want to declare using namespace Gdiplus;.)

The CGdiPlusBitmapResource class has several constructors and several overloaded Load functions. The overloaded functions simply allow lazy programmers, like myself, to not have to type MAKEINTRESOURCE. The main Load function takes the resource name and type as strings and is the key to the class. This code follows in its entirety:

inline
bool CGdiPlusBitmapResource::Load(LPCTSTR pName, LPCTSTR pType, 
                                  HMODULE hInst)
{
    Empty();

    HRSRC hResource = ::FindResource(hInst, pName, pType);
    if (!hResource)
        return false;
    
    DWORD imageSize = ::SizeofResource(hInst, hResource);
    if (!imageSize)
        return false;

    const void* pResourceData = ::LockResource(::LoadResource(hInst, 
                                              hResource));
    if (!pResourceData)
        return false;

    m_hBuffer  = ::GlobalAlloc(GMEM_MOVEABLE, imageSize);
    if (m_hBuffer)
    {
        void* pBuffer = ::GlobalLock(m_hBuffer);
        if (pBuffer)
        {
            CopyMemory(pBuffer, pResourceData, imageSize);

            IStream* pStream = NULL;
            if (::CreateStreamOnHGlobal(m_hBuffer, FALSE, &pStream) == S_OK)
            {
                m_pBitmap = Gdiplus::Bitmap::FromStream(pStream);
                pStream->Release();
        if (m_pBitmap)
        { 
          if (m_pBitmap->GetLastStatus() == Gdiplus::Ok)
            return true;

          delete m_pBitmap;
          m_pBitmap = NULL;
        }
            }
            m_pBitmap = NULL;
            ::GlobalUnlock(m_hBuffer);
        }
        ::GlobalFree(m_hBuffer);
        m_hBuffer = NULL;
    }
    return false;
}

I find the code very self explanatory, though those that know the return value of ::LoadResource is an HGLOBAL may find the apparent double copy using CopyMemory confusing. In brief CreateStreamOnHGlobal requires a HGLOBAL handle allocated by GlobalAlloc using the GMEM_MOVEABLE flag.

The Demo

The demo is a Visual Studio .NET 2003 project with ANSI and UNICODE builds. It allows you to load resampled JPG or PNG resources (For the curious, I took both photographs in Oahu, Hawaii for, and while filming content of, a multimedia product. One is of Laie Bay, the other is a sunset viewed from Waikiki.)

GDI+ Disclaimer

I am not a GDI+ expert, nor am I a big fan, even if I do find GDI+ occasionally very useful. Please don't ask me questions about it.

Why not IPicture?

I've been asked why I didn't use IPicture. The answer is threefold; first, IPicture does not support PNG images. Second, IPicture is pretty much only an image loader, with little more capability than the standard GDI bitmap calls. Third, IPicture decodes the image data immediately. JPG and GIF images will use more memory than this class.

Updates

22 April 2004

CreateStreamOnHGlobal now uses FALSE for the second argument since Bitmap requires that the memory be retained for at least JPG images and I decided to err on the side of caution. Interestingly, my testing showed this flag is often ignored, but I received reports that this wasn't always the case and was technically incorrect.

In addition, while fixing this bug I realized I wasn't clearing up the global memory on failure. That resulted in the code being rearranged as it is now.

15 June 2004

If Gdiplus::Bitmap::FromStream fails, I added what I believe is redundant, but more correct code in handling m_pBitmap. (Unfortunately, the documentation is silent on the subject as to whether NULL will always be returned on failure.)

3 September 2004

Added a section on GDI+ initialization.

Fixed a potential memory leak on image load failure in the sample application.