Double buffering winAPI

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

Without code I hardly imagine what is the actual situation... But you can try to handle WM_ERASEBKGND, return TRUE whenever you received them to skip erasing.

Answer 2

Hm. Before people rush in and close this topic as a duplicate, I'd better mention that your problem isn't double buffering per se, but flickering when repositioning controls, for which "manual" double buffering is only one of several solutions.

It might be that e.g. BeginDeferWindowPos & friends can fix the flickering.

Disclaimer: I once knew almost all the details of the Win16 API, but it's been some years since I did API-level programming.

Cheers & hth.,

– Alf

Answer 3

Handle WM_ERASEBKGND for your window and in the implementation exclude the rects of each of your child controls, then fill the remaining background appropriately and tell the framework that you have painted the background urself by returning true. Do the same thing for all other child controls which in turn hold other controls like tab control in your case.

See here for an example using MFC.

Answer 4

In .net there is ControlStyle.AllPaintingInWmPaint That should be set on each container window (so the main window and the tabs). I could not find a winapi equivalent. But what this does is to move the painting of the background from WM_ERASEBKGND to WM_PAINT. it also subtracts the child control's area from the parent to avoid flicker, It could be that you need to do this manually.

I am surprised WS_EX_COMPOSITED does not help. That should work, if you set that on the top-level window, and don't call RedrawWindow on the sub controls.

Also be sure to test with and without DWM/Aero. You can get different results.

Answer 5

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.