I was curious, in windows, what the back buffer is associated with - the device context, the window, or the rendering context. SwapBuffers() takes a handle to a device context as a parameter, which would lead one to believe it’s associated with the device context. However, it is equally feasible that it is associated with the rendering context. If this is the case, is a new back(and possibly front) buffer allocated with each wglMakeCurrent() call?
I’m trying to figure out the best way to handle having multiple windows - whether to keep one rendering context and call wglMakeCurrent() each time to assoicate it with a window, or to keep a context for each window to avoid a possible buffer allocation.
Do you driver developers know the answer to these?
Much appreciated.
J
Buffers are associated with windows (“drawables”), not contexts. In WGL, the pixel format is a property of the drawable.
If you create multiple contexts for a single drawable, they will have to share the drawable. Each will have independent OpenGL state, but they will render into the same buffer. They are even allowed to render at the same time, but the results are undefined if they do anything with any ordering hazards. I’d strongly suggest that you only let one context render at a time unless you really know what you are doing.
MakeCurrent can be thought of as establishing a link between a thread, a context, and a drawable. Thus, it takes an HDC and a HGLRC. The thread is implicit (the calling thread).
SwapBuffers does not need a context, because it does not use any OpenGL state. It only needs the drawable state, so it only takes an HDC as an argument.