Invalid OpenGL display context after switching between windows
I am having the following problem with OpenGL Application A (written in C ++): After switching to another window "B" (a child window of the same application or a completely different application) and then switching to "A", all OpenGL rendering is limited area "A" that was covered by "B".
- problem disappears after minimizing and re-maximizing window "A"
- the problem only occurs on one Windows 7 machine. When tested on many other machines (both Windows and Linux) everything works fine. Updating the graphics driver to the latest version didn't help either.
Is there an obvious coding error that could cause this behavior?
What's a good way to debug this type of error?
source to share
There are a number of aspects that can affect replay behavior in Windows. Given a few details in the question, I suggest checking the basics first:
-
First of all, on Windows, you need to create an OpenGL context window with these flags:
WS_OVERLAPPEDWINDOW | WS_CLIPSIBLINGS | WS_CLIPCHILDREN
-
In response,
WM_ACTIVATE
you must callwglMakeCurrent()
. -
In response,
WM_SIZE
you must callglViewport()
.
The behavior will of course depend on the hardware, Windows version, and driver version. All combinations will have their own quirks.
problem disappears after minimizing and re-maximizing window "A"
This causes redrawing and resizing, so it doesn't narrow the problem. For debugging, you can use WM_CHAR
to receive events on the keyboard and use the hotkey to force redraw (without the rest of the message flow). This will tell you if this is an activation issue.
... all OpenGL rendering is limited to area "A", which was covered by "B".
If the rendering is downsized to an overlapping area, then the visibility is likely messed up, for example by setting the viewport to a dirty rectangle during redrawing.
If the scaling is correct, but you only see the corner of the window being redrawn, the behavior you see is an occlusive window, which keeps the window's backup buffer behind, which only copies the saved bits when it is restored. This is clearly not enough for your repainting logic, and clip flags affect this behavior.
Another possibility is that the active GL context (from which only one thread exists) does not switch to the newly activated window until the repaint event has been handled. This operation will be activated.
As far as debugging strategies go, I would add some printf
to the event handlers (or use MessageSpy) so you can see the order of the events. The fact that this is only a specific combination of hardware and software means that you can rely on default behavior that differs slightly between versions. More detailed information you can provide will help narrow it down further.
source to share