Imagine a complex window layout with several windows which are expensive to redraw. Now say a scrollevent needs to update several of these windows simultaneously. The way I do this is to update the scroll position and call Refresh on the windows causing them to receive OnPaint events. However, some of the windows never receive their OnPaint event, causing them to lag dramatically when scrolling and updating only after scrolling has finished.
What I think is happening is the following: OnPaint events don't stack up in the windows message queue, i.e. there can only ever be one OnPaint event per window. This makes sense as you don't need to show an obsolete window state only to redraw it a moment later. However, since my OnPaint method is so expensive and since several windows are waiting to be repainted the first window in the queue will repaint and by the time it is finished there will already be new paint requests queued. This causes the second window in the queue to continually miss out.
I can see some workarounds, none of which I particularly like:
1) Alternate the windows' priority. I.e. send the first refresh to window one and then window two, the next refresh to window two and then window one. This will cause the windows to take turns in missing a repaint, making the glitch less obvious. It is hard to implement though since I need to dig up all places in the code that may cause a refresh and build in a toggle.
2) Don't use the message queue for refreshes at all. Instead cause an immediate redraw of all affected windows. This may lead to unnecessary, redundant redraws - losing even more performance. It'll also cause the scrollbar to stutter instead of the windows which I think will be even worse.
3) Obvious: speed up OnPaint. Easier said than done...
Any ideas? Any known workarounds? I'd think this to be a common problem?
(using C++ wxwidgets on windowsxp)