PDA

View Full Version : wglShareLists question.



Nutty
10-01-2002, 01:42 PM
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).]

PH
10-01-2002, 01:49 PM
RC1 is the original one.

V-man
10-01-2002, 04:10 PM
Why does this matter? You should be able to swap them, no?

V-man

solarforge
10-01-2002, 08:23 PM
Originally posted by V-man:
Why does this matter? You should be able to swap them, no?

V-man

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...

Ummm... I hope that's clear...

Leathal.

davepermen
10-01-2002, 10:21 PM
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..)

Asgard
10-01-2002, 11:53 PM
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 ;-)

knackered
10-02-2002, 01:47 AM
I'm more interested in why you're using wglsharelists, nutty?

Humus
10-02-2002, 03:55 AM
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.

knackered
10-02-2002, 04:11 AM
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?

ToolChest
10-02-2002, 05:37 AM
the pbuffer has its own device context, how do you do that?

PH
10-02-2002, 06:14 AM
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.

ToolChest
10-02-2002, 06:24 AM
very nice... I like it for the shared state, gl state changes can be expensive...

thanks!

Nutty
10-02-2002, 08:04 AM
Ahh right, I dont need another context? Thats even better.

What if I want my pbuffer a different pixel format to the framebuffers? Do I need a new context then?

Nutty

V-man
10-02-2002, 08:09 AM
This might explain the problems some people have posted previously, thinking its a bug. http://www.opengl.org/discussion_boards/ubb/smile.gif

OK, to be clear, if you call sharelist(rc1, rc2)

then the lists and textures you create thereafter and all previous ones of rc1 are available to rc2, but nothing in rc2 is available to rc1.

What if you want to have a chain of sharing like this

sharelist(rc1, rc2)
sharelist(rc2, rc3)
....

V-man

PH
10-02-2002, 08:52 AM
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.

Korval
10-02-2002, 10:20 AM
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.

Nutty
10-02-2002, 12:56 PM
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?

Asgard
10-02-2002, 01:04 PM
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.

Nutty
10-02-2002, 01:17 PM
aha! sorted, ta.

davepermen
10-02-2002, 09:41 PM
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.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Nutty
10-02-2002, 11:39 PM
dx8 is much bether in that way, really..

But dx8 isn't cross platform either!!! hahahaha!

How can you complain about gl being fiddly to do pbuffers on linux, macs etc, when dx8 doesn't do anything at all on these platforms?

Asgard
10-03-2002, 12:10 AM
Even if DX8 doesn't run on other platforms, it's a question of design. And the way render-to-texture works in DX8 is simply lightyears ahead of OpenGL. I have to agree with dave that the pbuffer design kinda sucks. So let's hope that we get OGL 2.0 soon which fixes that mishap.

Nutty
10-03-2002, 04:12 AM
IT's probably more of to do with the completely different way windows works to other operating systems. The only reason you're exposed to the kludgyness of it all, is because OpenGL _is_ cross platform. Therefore any setup relating to platform dependant features must go through windows code.

The fact you dont see this in dx8 means nothing. It's not ported to any other platform, so they can just stick a nice wrapper on the top of it, and call it render to texture. It's still doing the same stuff underneath.

Nutty

Nakoruru
10-03-2002, 04:20 AM
Nutty,

I do not think you can blame windows or opengl's portability. It is simply a matter of pbuffers being a poor design. Even if you consider the environment, I do not think that pbuffers is the only solution that would have worked. If it was, then you could complain about it being because of windows or because of opengl's design.

davepermen
10-03-2002, 04:28 AM
Originally posted by Nutty:
But dx8 isn't cross platform either!!! hahahaha!

How can you complain about gl being fiddly to do pbuffers on linux, macs etc, when dx8 doesn't do anything at all on these platforms?



its rather simple: in dx you don't need to use a windowsfunction to generate your rendertarget.

think about it. is a texture dependent on the os? it isn't. is a rendertarget? no. except it has to interfer with the os. when does it have to? if the os needs access to it. to show it. so the framebuffer has to interfer with the os, to display it in a window. there, a wgl func makes sence. but an offscreen buffer. thats just an array. it does by no means need to interfer with thet os. so there is no need for a wgl-extension at all.

GL_ARB_render_target
would be able to create buffers of arbitary size, with additional parameters to say it should be bindable as a simple 2d texture, or a cubemap, or what ever. or, it does interfer with the os.. some /*flags*/|GL_OS_ACCESS_ARB|/*other flags..*/
and then you need to use some wgl
GL_WGL_render_target
HGLRC hrc = wglMountTargetToHDC(hdc);
wglUnmountTarget(hrc,hdc);

something in this way.. (the os-mounting is only needed if its a visible framebuffer for the os, the "screen")

but making simple pixelbuffers os dependend is utterly stupid.

in dx, you just set a flag at texturecreationtime.. render_target..

Asgard
10-03-2002, 04:31 AM
IT's probably more of to do with the completely different way windows works to other operating systems.

But windowing systems don't have anything to do with render-to-texture? What I want is create a texture object, attach a buffer to it, set that buffer as active render target, and render to it. I don't want to have a separate rendering context, nor do I want a full-featured pbuffer. That's the way it works in DX 8. It's also the way it's currently proposed in the OpenGL 2.0 drafts, by the way.

Another thing that OpenGL 2.0 hopefully finally gets rid of, is the platform-dependent routines to specify depth and stencil buffer formats, which semantically has nothing to do with windowing systems. Of course the implementation to create these buffers will most likely be platform-dependent, but in the end OpenGL is only a platform-independent API. All the implementations (that is, drivers) are platform-dependent code for a large part. And I think that not defining things as wglMakeCurrent as core part of the GL API was a mistake.


The fact you dont see this in dx8 means nothing. It's not ported to any other platform, so they can just stick a nice wrapper on the top of it, and call it render to texture. It's still doing the same stuff underneath.

I highly doubt that it's doing the same stuff underneath. There's no separate rendering context in DX for render-textures so there's no complete state change when I decide to render to a texture. The render context switching for RTT in OpenGL (caused by the use of pbuffers for doing RTT), is a big design flaw IMHO.