CODEWITHSUNDEEP
c++opengl
Jakob Erdmann
Jakob Erdmann

Reputation: 190

Invalid OpenGL drawing context after switching between windows

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'.

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

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

Upvotes: 3

Views: 1780

Answers (1)

gavinb
gavinb

Reputation: 20028

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

  • 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 printfs 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.

Upvotes: 3

Related Questions