Why Direct Drawing Flickers
When OnDraw or OnPaint draws directly to the screen DC, Windows typically erases the background first (via WM_ERASEBKGND) and then paints each element in sequence, so the user briefly sees the blank background followed by shapes appearing one at a time — visible as flicker, especially on views that redraw frequently, such as during resizing, animation, or rapid data updates. The fix is double buffering: render the entire frame to an off-screen bitmap first, then copy that finished bitmap to the screen in a single fast BitBlt, so the user only ever sees complete frames.
Cricket analogy: Like a stadium's big screen showing a fully composed replay graphic only once it's completely rendered, rather than building it up piece by piece live in front of the crowd, double buffering assembles the whole frame off-screen before it's ever displayed.
Implementing a Memory DC
The standard pattern creates a CMemDC-style memory device context compatible with the screen DC via CreateCompatibleDC, selects in a CBitmap created with CreateCompatibleBitmap sized to the client rectangle, performs all normal drawing (background fill, shapes, text) against that memory DC exactly as you would against the screen DC, and finishes with a single BitBlt from the memory DC to the real screen DC using SRCCOPY — after which the memory DC's original bitmap must be reselected and the temporary bitmap and DC destroyed (or wrapped in a scope-based helper class) to avoid GDI leaks.
Cricket analogy: Like a groundskeeper preparing a complete practice pitch off to the side that exactly matches the main pitch's dimensions before it's ever used, CreateCompatibleDC and CreateCompatibleBitmap build an off-screen surface matching the real screen's characteristics.
Handling WM_ERASEBKGND and Resizing
Because double buffering already paints a full background inside the memory DC, letting the default WM_ERASEBKGND handler also erase the real window background is redundant and can reintroduce the very flicker you're trying to eliminate; overriding OnEraseBkgnd to simply return TRUE (without calling the base class) skips that default erase. Since the off-screen bitmap is sized to the client rectangle, it must also be recreated whenever the view is resized — typically by recreating it lazily inside OnDraw whenever the cached bitmap's size no longer matches the current client rectangle.
Cricket analogy: Like a groundskeeper not needing to re-roll a pitch that was already freshly prepared moments earlier, overriding OnEraseBkgnd to skip the redundant erase avoids doing background work that the memory DC already handled.
BOOL CMyView::OnEraseBkgnd(CDC* pDC)
{
return TRUE; // skip default erase; the memory DC paints the full background
}
void CMyView::OnDraw(CDC* pDC)
{
CRect rcClient;
GetClientRect(&rcClient);
CDC memDC;
memDC.CreateCompatibleDC(pDC);
CBitmap bitmap;
bitmap.CreateCompatibleBitmap(pDC, rcClient.Width(), rcClient.Height());
CBitmap* pOldBitmap = memDC.SelectObject(&bitmap);
// Fill background and draw everything against memDC, not pDC
memDC.FillSolidRect(&rcClient, RGB(255, 255, 255));
memDC.Ellipse(20, 20, 180, 140);
// One fast copy to the real screen DC
pDC->BitBlt(0, 0, rcClient.Width(), rcClient.Height(), &memDC, 0, 0, SRCCOPY);
memDC.SelectObject(pOldBitmap); // restore before bitmap is destroyed
}Always reselect the memory DC's original bitmap (SelectObject(pOldBitmap)) before the temporary CBitmap goes out of scope. If the bitmap is destroyed while still selected into the memory DC, you get undefined behavior — the same rule that applies to pens and brushes applies to bitmaps used for double buffering.
- Flicker comes from the visible sequence of background erase followed by piecemeal drawing directly on the screen DC.
- Double buffering draws the entire frame to an off-screen memory DC first, then copies it to the screen in one BitBlt.
- CreateCompatibleDC and CreateCompatibleBitmap create a memory DC and backing bitmap matched to the screen DC's characteristics.
- Overriding OnEraseBkgnd to return TRUE skips the redundant default background erase that would otherwise still cause flicker.
- The off-screen bitmap must be resized whenever the client area's size changes.
- The memory DC's original bitmap must always be reselected before the temporary bitmap is destroyed, to avoid GDI leaks.
- Double buffering trades a small amount of memory and one extra BitBlt for a substantial visual quality improvement in dynamic views.
Practice what you learned
1. What is the root cause of flicker in a naive MFC view that draws directly to the screen DC?
2. What is the core technique behind double buffering in MFC?
3. Why should OnEraseBkgnd be overridden to return TRUE when using double buffering?
4. What must be done with the memory DC's original bitmap before the temporary CBitmap is destroyed?
5. When must the off-screen bitmap used for double buffering be recreated?
Was this page helpful?
You May Also Like
Drawing with CDC
A practical tour of the CDC drawing API — lines, shapes, text, and pens/brushes — and the conventions MFC applications follow to render correctly inside OnDraw and OnPaint.
GDI Basics in MFC
An introduction to the Windows Graphics Device Interface (GDI) and how MFC's CDC class family wraps device contexts, handles, and GDI objects for safe, structured drawing.
Custom Drawing and Owner-Draw
How MFC lets you take over rendering of standard controls — buttons, list boxes, combo boxes, list controls — through the owner-draw mechanism and custom-draw notifications.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics