CODEWITHSUNDEEP
cocoawinapiopengl
Vojtěch Melda Meluzín
Vojtěch Melda Meluzín

Reputation: 1187

OpenGL context stops working when user moves the window into a different display

I'm using OpenGL to speed-up GUI rendering. It works fine, but when user drags the window into a different display (potentially connected to a different GPU), it starts rendering black interior. When the user moves the window back to the original display, it starts working again. I have this report from Windows XP, I'm unfortunately unable to check on Win 7/8 and Mac OS X right now. Any ideas what to do about it?

Upvotes: 1

Views: 422

Answers (1)

datenwolf
datenwolf

Reputation: 162164

In the current Windows and Linux driver models OpenGL contexts are tied to a certain graphics scanout framebuffer. It's perfectly possible for the scanout framebuffer to span over several connected displays and even GPUs, if the GPU architecture allows for that (for example NVidia SLi and AMD CrossFire).

However what does not work (with current driver architectures) are GPUs of different vendors (e.g. NVidia and Intel) to share a scanout buffer. Or in the case of all NVidia or AMD if the GPUs have not been connected using SLI or CrossFire.

So if the monitors are connected to different graphics cards then this can happen.

This is however only a software design limitation. It's perfectly possible to separate graphics rendering from display scanout. This forms in fact the technical base for Hybrid graphics, where a fast GPU renders into the scanout buffer memory managed by a different GPU (NVidia Optimus for example).

The low hanging fruit to fix that would be to recreate the context when the window passes over to a screen conntected to a different GPU. But this has a problem: If the Window is split among screens on one of the screens it will stay black. Also recreating a context, together with uploading all the data can be a length operation. And often in situations like yours the device on the other screen is incompatible with the feature set of the original context.

A workaround for this is to do all rendering on a off-screen framebuffer object (FBO), which contents you then copy to CPU memory and from there to the target Window using GDI operations. This method however has a huge drawback of involving a full memory roundtrip and increased latency.

The steps to set this up would be:

  • Identify the screen with the GPU you want to use

  • Create a hidden window centered on that screen. (i.e. do not WS_VISIBLE as style in CreateWindow and do not call ShowWindow on it).

  • Create a OpenGL context on this window; it doesn't have to be double buffered PIXELFORMAT, but usually double buffered gives better performance.

  • Create the target, user visible window; do not bind a OpenGL context to this window.

  • Setup a Framebuffer Object (FBO) on the OpenGL context

    • the renderbuffer target of this FBO is to be created to match the client rect size of the target window; when the window gets resized, resize the FBO renderbuffer.
    • setup 2 renderbuffer object for double buffered operation

  • Setup a Pixel Buffer Object (PBO) that matches the dimensions of the renderbuffers

    • when the renderbuffers' size changes, so needs the PBO

  • With OpenGL render to the FBO, then transfer the pixel contents to the PBO (glBindBuffer, glReadPixels)

  • Map the PBO to process memory using glMapBuffer and use the SetDIBitsToDevice function to transfer the data from the mapped memory region to the target window device context; then unmap the PBO

Upvotes: 3

Related Questions