3

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?

Jakob Erdmann
  • 190
  • 1
  • 7
  • 1
    most of the times, this shouldn't be a error cause by cording. According to your testing, this issue occurs in only one machine. What is the machine configuration ? – ANjaNA May 11 '15 at 07:58
  • maybe resetting `glViewport` when the application A is activated would work – tmlen May 11 '15 at 08:09
  • 1
    My bet is buggy/bad/wrong drivers ... Is this Intel or ATI ? Intel has big problems with multiple Opengl Contexts per single App and ATI(AMD) card drivers are extremly sensitive to memory leaks within your App. For Intel you are out of luck (switch to GDI where you can) and for ATI debug or change the order of some gl calls that sometimes helps and most of all update drivers **Add more info about what your apps do/use what OS is it GL/GLSL what version, compatibility/core profile and more ** similar to http://stackoverflow.com/q/19099162/2521214 but I got no answers nor comments :( – Spektre May 11 '15 at 08:34
  • Also make sure that your windows are changing current GL context in events like OnActivate,OnResize,...And setting it to NULL before close ... – Spektre May 11 '15 at 08:51
  • 1
    Well, I _can_ imagine weird scenarios where an application error would result in such kind of behavior, e.g. some situations where the pixel ownership test fails for some area due to another window in front of it, in combination with some specifc per-pixel tests like stencil testing or weird usage of the depth test. But, as vague as this question is posed, it is next to impossible to give a useful recommendation. However, one thing: check if the windows "Aero" desktop compositor is turned off on that machine, and maybe even toggle it and check if it makes any difference. – derhass May 11 '15 at 19:01

1 Answers1

3

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.

gavinb
  • 19,278
  • 3
  • 45
  • 60