fullscreen + FBO + alt-tab = trouble

[remdul]

I'm having serious problems in my program when alt-tabbing from my fullscreen OpenGL program to other software (notepad) in Windows XP, NV8800GT (varying NV hardware, recent drivers, different machines). Appears to depend on the existence of FBOs, and the dimensions of the texture attached to them.

After pressing the keys and the display has switched resolution, there is typically a ~3 sec hang. Other application windows have blacked out elements (some toolbar, text boxes etc) during this hang. After a few more seconds of stutter, everything becomes responsive again. Could be better, but so far so good.

When Alt-Tabbing back into the program, the display switches resolution and the screen becomes black, takes about half a minute before it appears again, several seconds of stutter and unresponsiveness and the program continues to run as expected.

If the FBOs are relatively large/numerous (e.g. 1x 2048x2048 16-bit depth shadow map, 1x 1024x768 RGB8+depth24 RBO, 2x 256x256 RGB8 for post processing) the program becomes as good as unrecoverable. Subsequently significant difficulty to terminate the app via task manager (hard reboot often more convenient). Smaller FBOs make the problem more manageable. There's even a noticeable difference of several seconds between a 16x16 and 128x128 texture attached to a single FBO.

FBO status are all 'complete', cannot detect other GL errors; all appears to be working as expected. No problems at all in windowed mode. Using SDL.

Does anyone have tips to improve ALT-TAB behavior or other hints?

[Stephen A]

This sounds like a typical low-memory condition. How much memory do you have? Does the OS hit the disk when you alt-tab?

When running low on memory, the OS needs to page your data out when you alt-tab away from your program and page it in when you alt-tab in again. Fullscreen modes tend to exaggerate the issue, as the OS (correctly) gives priority to the fullscreen application over any background process.

Try switching to windowed mode when your process loses focus and switching back to fullscreen mode afterwards. There is a chance this will improve behavior.

While OpenGL does not strictly need this (as the drivers keep a backup copy of all data), D3F applications destroy and recreate everything when alt-tabbing ("device lost" event). This won't be faster than letting the OS page in data, but it does give you control over the process, which may be desirable.

Of course, there's always the possibility that you are hitting some obscure driver bug, so consider testing with a few different drivers first.

[remdul]

This sounds like a typical low-memory condition. How much memory do you have? Does the OS hit the disk when you alt-tab?

Memory isn't the problem, or well, 3GB ought to be enough. It does hit the disk very briefly, but seems not directly related. I have virtual memory disabled on my dev machine, so this should not happen anyway. From user reports it behaves the same on default XP setups. If memory were indeed a problem I would expect to notice this in windowed mode one way or another.


When running low on memory, the OS needs to page your data out when you alt-tab away from your program and page it in when you alt-tab in again. Fullscreen modes tend to exaggerate the issue, as the OS (correctly) gives priority to the fullscreen application over any background process.
Yes, this is what I suspect is happening.


Try switching to windowed mode when your process loses focus and switching back to fullscreen mode afterwards. There is a chance this will improve behavior.
Good idea.


While OpenGL does not strictly need this (as the drivers keep a backup copy of all data), D3F applications destroy and recreate everything when alt-tabbing ("device lost" event). This won't be faster than letting the OS page in data, but it does give you control over the process, which may be desirable.
Indeed. I noticed a similar hang before after the app exited, where it failed to delete an FBO before closing and destroying the window. Rearranging some destructors fixed this.

I bet that deleting and re-creating the FBOs is probably faster than waiting for the OS/drivers to move the memory around.

Thanks!