Question

Okay, so in my application, there are a bunch of winAPI and a few custom controls. Yay…

Now, normally, they will just quietly redraw themselves for animations, state changing, ect…. and it all works fine.

But I have a method of class Window called fix(). This is called whenever the whole window needs to be updated. It resizes the controls and invalidates the window.

When this happens, the background is drawn, then the tab control, then all the others on top. This causes very irritating blinking, especially when resizing the window (because of constant calls to fix()).

What I have tried:

• WS_EX_COMPOSITED. This only double-buffers the individual controls. Its an improvement, but the flickering inevitably remains.
• Turning off background drawing. Hardly solves the problem, and actually makes matters worse.

So: I need a technique/method/whatever to allow me to double-buffer the window in its entirety. I figured that handling the WM_PAINT message by myself might be a solution, but I wouldn’t know where to begin. I have a horrible feeling this isn’t even possible…

Please help, this is a critical issue. I will be very relieved when this stupid little issue is fixed.

Answer 1

It is at this time that one realized the depths of Microsofts disregard for native developers. One could in fact start to harbor paranoid delusions that Microsoft has purposely broken native painting in order to force native developers to move to WPF.

First, consider WS_EX_COMPOSITED. WS_EX_COMPOSITED seems to be the mustard :- it says that it enforces a botton to top paint order for child controls, and basically that WM_PAINT messages get handled in a batch. It says it was added in Windows 2000 (5.0) and, a few lines down, that it does not work with desktop composition enabled. i.e. It stops working as of Windows Vista (6.0), unless aero glass is turned off and who is going to do that?

Then, there are two possible “hacks” to try and get flicker free painting to work:

• First, you need to mimimize the amount of overpainting. WS_EX_CLIPCHILDREN | WS_EX_CLIPSIBLINGS are necessary to ensure that any particular area of the window is only painted once. BeginDeferWindowPos is also necessary to batch up resizing operations to ensure that transient states – where one window overlaps another – don’t happen (i.e. when Window A has been resized but Window B has not).

Of course, when you are trying to draw a skinned dialog, or use Group boxes, or tab controls, or any number of other restrictions, WS_EX_CLIPSIBLINGS is just not appropriate.

• WM_SETREDRAW is a magic message. There is no API to access this functionality: WM_SETREDRAW is directly handled by DefWindowProc to essentially mark the window as hidden for the duration. After WM_SETREDRAW, FALSE is sent, calls to GetDC/GetDCEx/GetWindowDC etc using the parent window handle (and all its children) will return a DC that won’t draw on the screen. This gives you a chance to do all kinds of stuff to the child windows, when you are done send a WM_SETREDRAW,TRUE, (and then repaint the window manually). All the child windows will – of course – paint in their own time, and after the parent window has done its erase background, so WM_SETREDRAW is no kind of panacea.

After breaking WS_EX_COMPOSITED, In .NET’s WinForms and WPF re-wrote the controls from the ground up to not use the native controls, so they could bake in buffered painting there. And alpha support too.