Question about double buffering concept

[steverex1000]

I am using double buffer to avoid flickering... But bit confused about what it actually is???

Shall i store all the coordinates of the shapes drawn and re project it to the screen.... Is this double buffering??? But in this still flickering happens while drawing a shape...

If double buffering is creating a compatible bitmap of the client area and redrawing it on the window,will it prevent the flickering when a new shape is being drawn???

Thanks in advance......

[JVene]

With respect to typical GUI display, double buffering is the act of drawing on a bitmap representing the window, then blitting the final result to the display.

It does remove flicker.

Keep in mind all of your drawing is targeted at the bitmap. This means all of the time taken to process the instructions to create the final result will occur without being seen.

One key point in the double buffering technique is to avoid erasing the background. If you don't stop the background erasure, you will still have a flicker associated with the cycle of erase-blit-erase-blit. What you want is to rely on the fact that the bitmap is a complete replacement of the entire window area, and therefore the erasure, if there is one, occurs on the bitmap, not on the display.

[steverex1000]

Do u mean instead instead of drawing on Device context of the screen i should draw on a bitmap instance..
Like instead of "hdc" which is

hdc=GetDC(hwnd);
Rectangle(hdc,100,100,200,200);

i should use "hBmp" object

Am i correct??

But anyhow i need the hdc for creating the bitmap right??

I believe bit of sample code in Win32 SDK will be helpful..

Can u post some or forward me to the URL of the same????

[olivthill]

If you program without MFC, you can avoid the default erasure with these two lines:

      case WM_ERASEBKGND:
         return(1); // Prevent erasing the background to reduce flickering

[steverex1000]

thanks olivthill... but i am using Win32 SDK

[DHillard]

Basically...

Handle WM_CREATE and create a compatible memory DC.

Handle WM_SIZE and create a compatible bitmap the size of your client area. If it exists, be sure to destroy it first.

Select the created bitmap into the compatible memory DC.

Do all drawing to the memory DC. This will cause the drawing to be "saved" to the bitmap that is selected into the memory DC.

On WM_PAINT, just do a single BitBlt of the memory DC to the screen DC.

Handle the WM_ERASEBKGND like they said in the prior posts.

Handle WM_DESTROY and delete the bitmap and memory DC.

[steverex1000]

>>Select the created bitmap into the compatible memory DC.

>>Do all drawing to the memory DC. This will cause the drawing to be "saved" >>to the bitmap that is selected into the memory DC.

In which message the above points should be handled and how???

Is it like Rectangle(hmemoryDC,100,100,200,200);


>>Handle the WM_ERASEBKGND
what should be done here??

[DHillard]

Is it like Rectangle(hmemoryDC,100,100,200,200);

Yes. Exactly.

Once you create a memory DC with CreateCompatibleDC and you create a compatible bitmap with CreateCompatibleBitmap and select that bitmap into that memory DC, just route all your GDI drawing functions to use that memory DC instead of the screen DC that you'd normally use.

Where it's handled depends on what it's doing. Keep in mind that since you're doing your drawing to a bitmap (the one selected in the memory DC), this acts as an "offscreen buffer". Once it's drawn, when your application needs to repaint itself (WM_PAINT), it really only needs to redisplay the offscreen bitmap that you've already drawn (painted).

Make sense?

[steverex1000]

Yes.... i ll implement it and get back to u..