Drawing Bitmaps

Hi - quick couple of questions regarding drawing bitmaps...

1. MSDN says.. "After painting with a common DC, the ReleaseDC function must be called to release the DC. " - Does this mean it must absolutely be released within the one WM_PAINT message? In otherwords, it is not OK to keep the DC around until the end of the program?

2. In the following code I want to draw two bitmaps, I can see a number of problems with the code below, i.e. I am not reinstating the old bitmap. How do I go about rewriting this properly - so I can draw both images in the window without causing any resource leaks?

Code:

PAINTSTRUCT ps;
			
dc = BeginPaint(hwnd, &ps);
dcMem = CreateCompatibleDC(NULL);
SelectObject(dcMem, hBucket);
BitBlt(dc, 0, 200, 140, 160, dcMem, 0, 0, SRCCOPY);
SelectObject(dcMem, hBubble);
BitBlt(dc, 0, 0, 400, 160, dcMem, 0, 0, SRCCOPY);
DeleteDC(dcMem);
EndPaint(hwnd, &ps);

Cheers.

I recommend using a class like this to manage your bitmaps. Its hard to keep track of all those HDCs and HBITMAPs .

Hey, thanks - that is really quite useful

To fix the leaks

hOriginalBMP = SelectObject(dcMem, hBucket);
//use, then return to original state
SelectObject(dcMem,hOriginalBMP);
//now delete DC

// on close delete the bitmaps

The way you are doing the paint will be slow if the drawing get more complex. Look at double buffering, plenty of examples here.

or simply

Create the DC in the WM_INIT / CREATE or when you load the bitmaps. Use a global or static local in the callback.

Delete the DC in the WM_CLOSE or when you free the bitmaps.

Does this mean it must absolutely be released within the one WM_PAINT message? In otherwords, it is not OK to keep the DC around until the end of the program?

In your case, yes. But you can get a HDC from a call to GetDC(hWnd) at the start of the program, then use that for drawing until you call ReleaseDC(hWnd) at the end of the program. Then, you can also create a back-buffer and bitmap-holding buffer after you get the main HDC, and keep those too until you decide to quit the program.

An added advantage of this method is that you aren't limited to drawing within the WM_PAINT message; you can redraw everything that needs redrawing at any time you choose. There are probably drawbacks to this method too, but I've successfully used it in 3 or 4 games already, and plan to use it in more (although I have a DirectDraw7 wrapper written too, with pretty much the same features).

About Window Classes

If no device-context style is explicitly given, the system assumes each window uses a device context retrieved from a pool of contexts maintained by the system. In such cases, each window must retrieve and initialize the device context before painting and free it after painting.

To avoid retrieving a device context each time it needs to paint inside a window, an application can specify the CS_OWNDC style for the window class. This class style directs the system to create a private device context — that is, to allocate a unique device context for each window in the class. The application need only retrieve the context once and then use it for all subsequent painting.

Windows 95/98/Me: Although the CS_OWNDC style is convenient, use it carefully, because each device context uses a significant portion of 64K GDI heap.

GetDC() documentation

Windows 95/98/Me: There are only 5 common DCs available per thread, thus failure to release a DC can prevent other applications from accessing one.

If you want to keep a DC handy, use the either CS_CLASSDC or CS_OWNDC when you register the window class.

>>only 5 common DCs available per thread
>>can prevent other applications from accessing one.
Don't other applications run in separate threads?

Besides which, I don't think my method uses more than 1 common DC (by 'common', I'm assuming it means one that you don't create yourself).