The wglShareLists function enables multiple OpenGL rendering contexts to share a single display-list space.
BOOL wglShareLists(
HGLRC hglrc1, // OpenGL rendering context with which to share
// display lists
HGLRC hglrc2 // OpenGL rendering context to share display lists
);
Parameters
hglrc1
Specifies the OpenGL rendering context with which to share display lists.
hglrc2
Specifies the OpenGL rendering context to share display lists with hglrc1. The hglrc2 parameter should not contain any existing display lists when wglShareLists is called.
The amazing M$ documentation makes it virtually impossible for me to decide which bloody Rendering context it means for each paramter.
Which is the original Rendering context (the one associated with the frame buffer when opening the window), rc1, or rc2?
It looks like rc2 to me. That right?
ta,
Nutty
[This message has been edited by Nutty (edited 10-01-2002).]
Originally posted by V-man:
[b]Why does this matter? You should be able to swap them, no?
V-man[/b]
It matters if your creating textures in one context and sharing with another – if you create in the second context (I think this is right… then normally the texture can’t be used by the first context because you haven’t shared the resources of the second context…
if i interpet it correctly, the second parameter is “source” and the first is “destiny”…
but on the other hand, how about they both share their stuff together, so that each one has the others data… then it wouldn’t mather (i think thats what v-man ment…)
I had to find out the hard way that the order actually matters. I had created a context with a couple of texture and program objects and then created a new context that should also have access to those objects. Of course, I accidentally called wglShareLists with the contexts swapped and was wondering why I didn’t get any textures in the second context, even though I had just called wglShareLists before.
So watch the parameter order with wglShareLists or it’ll cost you hours of frustration, anger, and whatnot
Saving texture memory I suppose, would be wasteful to upload the same textures to two different contexts.
I always use wglShareLists when doing render to texture with WGL_ARB_render_texture.
Yes, but you can use your main RC to render to the pbuffer - why use another+sharelists? Surely it would just cause an unnecessary stall as the new RC is switched to?
Create a pbuffer with a pixel format that is “compatible” with the visible context. Then choose wglGetCurrentContext instead of wglCreateContext. That way you have a shared rendering context and a single set of state. Personally, I haven’t found it to be any faster than a seperate context.
What if I want my pbuffer a different pixel format to the framebuffers? Do I need a new context then?
Yes, I find this really annoying too. You even need to have depth, stencil and double buffered set in the pbuffer format for the pixel formats to be compatible ( if you have those in your visible context ). The size can vary though.
The hglrc2 parameter should not contain any existing display lists when wglShareLists is called.
I think this line makes it perfectly clear (though it requires a bit of thought). If #2 isn’t supposed to have display lists, it can’t possibly be the source. Therefore, it is the destination, and #1 is the source.
erm… call my stupid if you want, but if I dont create a seperate context for my pbuffer, How do I specify to render into the pbuffer or the framebuffer?
By specifying the HDC of the pbuffer in the call to wglMakeCurrent when you want to render into the pbuffer, or the HDC of the window for rendering into the window.
imho, the whole pbuffer design/structure is extremely flawed. stupid in fact.
take sdl, and try to code crossplatform, and you see what i mean… there is no platform independent way to create pixelbuffers. why not just some settings for the textures when you create it? and then glSetTarget or so? and glSetTarget(0) sets to the mainbuffer…
dx8 is much bether in that way, really…
and i would like to choose my target/source depthbuffer (incl stencil) and colorbuffer independent.
but oh well, dunno if they get a way around this… till then, i render on the backbuffer and glCopySubImage2D…
then normally the texture can’t be used by the first context because you haven’t shared the resources of the second context…
