Re: Aaarrrggghhh -- that ugly flicker!

From: Michael Culley (mculley_at_NOSPAMoptushome.com.au)
Date: 10/06/04 

Date: Wed, 6 Oct 2004 13:50:53 +1000

"Rob" <none> wrote in message news:OILGlM1qEHA.592@TK2MSFTNGP11.phx.gbl...
> I'm not sure it supports your
> view that it's easier to draw directly to the window

Yes, I should have thought about that more before I wrote it. What I really
meant was it is often better just to draw straight to the window. Quite
often it is more difficult to draw direct to the screen.

> but it definitely
> illustrates that double buffering is often an unnecessary "first resort".
> Here's an interesting article on how to eliminate flicker. It's aimed at
> the C language but I think it's still useful.

What it says in regards to double buffering makes a lot of sense:

A common method to completely eliminate flickering windows is to use a
technique called double-buffering. This basic idea is to draw a window's
contents into an off-screen buffer, and then transfer this buffer to the
screen in one fell-swoop (using BitBlt). This is a pretty good way to reduce
flicker, but is often overused, especially by programmers who don't really
understand how get efficient drawing working.

This method is a little slow, because the offscreen memory-DC is created
from scratch every time the window needs to be drawn. A more efficient
method would be to create the memory DC only once, big enough so that the
entire window can be painted at any time. When the application terminates,
the memory DC would then be destroyed. Both these methods are potentially
quite memory-intensive, especially if the memory DC needs to be the size of
a screen (1024 * 768 * 32 bytes=2.5 Mb).
Double-buffering will also be twice as slow as it needs to be. Because you
are drawing once to the memory-DC, then again during the "blit", you are
using up clock cycles when you don't need to. Granted, a fast graphics card
will perform a BitBlt very quickly, but it's still wasted CPU.

If your application needs to display quite complicated information (say,
like a web-page), then you would need to use the memory-DC method. Take
Internet Explorer, for instance. There is no way it would be able to render
a web-page with no flickering without using double-buffering.

Double-buffering doesn't have to be used to paint a whole window. Imagine
that you had just a small portion of a window that contained a complex
graphic object (maybe a semi-transparent bitmap or something). You could use
an off-screen DC to draw just this one region, and BitBlt that to the
screen, whilst drawing the rest of the window normally.

Sometimes though, with a little careful thinking, it is often possible to
avoid double-buffering and draw straight to the screen. As long as you don't
break the golden rule, "Never draw over the same pixel twice", you will
achieve flicker-free drawing. 

--
Michael Culley

Relevant Pages

  • GDI+ drawing speed within MFC dialog (help)
    ... I need to draw a raw data plot into a framed area of a bigger MFC ... dialog window. ... performance of the system and found a useful set of benchmark programs at http://www.codeproject.com/vcpp/gdiplus/gdiplusspeed.asp From these I concluded that the initial draw speed via a cached bitmap was sufficient for my data update rate, and the exposure redraw rate was also excellent. ... I created a simple static frame as the container for the GDI+ plot and timed the code. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Aaarrrggghhh -- that ugly flicker!
    ... meant was it is often better just to draw straight to the window. ... This method is a little slow, because the offscreen memory-DC is created ... Double-buffering will also be twice as slow as it needs to be. ...
    (microsoft.public.vb.winapi)
  • Re: image is not redrawed sometimes when I bring my window to fore
    ... it is erroneous to draw directly on the dialog except in extremely rare and exotic ... In addition, any attempt to paint in some other window is erroneous, and more to the ... you download Microsoft SDK, then look at DirectShow samples, you would see ... HWND hWnd; ...
    (microsoft.public.vc.mfc)
  • Re: Exception (Access Violation) within MFC code
    ... square shape on the current window when i click a toolbar button. ... describe to you anything else you need to know about it, i just dont want to ... a handle to draw this shape when running the updatewindow function. ... Joshua Weir ...
    (microsoft.public.vc.mfc)