在Windows之间切换后无效的OpenGL绘图上下文

Question

I experience the following problem with an OpenGL application 'A' (written in C++): After switching to a different window 'B' (either a child window of the same application or a completely different application) and then switching back to 'A', all OpenGL rendering is confined to the area of 'A' that was covered by 'B'.

• the problem goes away after minimizing and re-maximizing window 'A'
• the problem only occurs on a single windows 7 machine. When testing on many other machines (both windows and Linux) everything works fine. Updating the graphics driver to the latest version also did not help.

Is there an obvious coding error that would cause this behavior?

What is a good way to go about debugging this type of error?

Answer 1

There are a number of aspects that could impact repainting behaviour on Windows. Given the few details in the question, I suggest checking the basics first:

• First of all, on Windows, you need to create the OpenGL context window with these flags: WS_OVERLAPPEDWINDOW | WS_CLIPSIBLINGS | WS_CLIPCHILDREN WS_OVERLAPPEDWINDOW | WS_CLIPSIBLINGS | WS_CLIPCHILDREN

• In response to WM_ACTIVATE , you should be calling wglMakeCurrent() .

• In response to WM_SIZE , you should be calling glViewport() .

The behaviour will certainly vary by hardware, Windows version, and driver version. All combinations will have their own quirks.

the problem goes away after minimizing and re-maximizing window 'A'

This is forcing a repaint and a resize, so doesn't narrow down the problem very much. For debugging, you could use WM_CHAR to get keyboard events, and use a hotkey to force a repaint (without all the other message flow). That would tell you if it's an activation issue.

...all OpenGL rendering is confined to the area of 'A' that was covered by 'B'.

If the rendering scaled down to the overlapped area, then the viewport is probably getting messed up, for example setting the viewport to the dirty rect during a repaint.

If the scaling is correct but you are only seeing a corner of the window being repainted, the behaviour you are seeing is the occluding window saves the backing buffer of the window behind, which repaints just the saved bits when it gets restored. This is obviously not sufficient for your repainting logic, and the clip flags affect this behaviour.

Another possibility is that the active GL context (of which there is only one per thread) is not getting switched to the newly activated window before the repaint event gets processed. The activate handling above would address this.

As for debugging strategies, I'd put some printf s in your event handlers (or use MessageSpy) so you can see the order of events. The fact that it is only a particular combination of hardware and software means that you may be relying on default behaviour that is slightly different between versions. Any more details you can supply would help narrow this down further.