[Qt-interest] deferral of WM_PAINT messages for hosted hWnds (?)

[Ross Bencina]

On Windows, my Qt App hosts native HWNDs from 3rd party (non-Qt) plugins in 
an MDI-like area where "pseudo windows" can be dragged around and 
overlapped. What I'm calling "pseudo windows" are really just a QWidget 
subclass which renders window-frame type chrome, supports mouse based 
dragging, and acts as a parent for a content widget (which can be a QWidget 
or a native HWND) -- this is similar to the way Qt's built-in MDI 
implementation works. Incidentally, these window frame QWidgets have 
WA_NativeWindow set so that z-order stacking works when some of them contain 
native HWNDs.

I have noticed significantly different redraw-behavior between my Qt-based 
widgets and embedded native HWNDs. It seems like Qt is delaying delivery of 
WM_PAINT messages to the native HWNDs while I'm dragging my psuedo-windows 
around. This creates ugly redraw artifacts because the native HWNDs get 
erased when new areas get exposed but not redrawn for significant periods of 
time. On the other hand, the Qt widgets seem to get updated immediately.

It only seems to do this when a topmost pseudo window overlaps native HWND 
and Qt-drawn areas. If my topmost pseudo window is completely over a 
(larger) native HWND then the HWND seems to get WM_PAINT messages straight 
away.

Can anyone explain this behavior and suggest any way to get WM_PAINT 
messages to my hosted native HWNDs more quickly? Perhaps I don't have the 
right Qt flags set on the QWidget which hosts the HWNDs or something?

Also, while I'm asking, can anyone suggest a way of getting Qt or Windows to 
double buffer dragging of QWidgets with WA_NativeWindow set? At the moment 
dragging QWidgets around on top of each other causes visible artifacts on 
exposed areas of non-frontmosts widgets (ie I'd like moving the frontmost 
widget and redrawing exposed areas to be atomic).

Thanks!

Ross.