One RC, multiple DC's

Hello,

I am a newbie at OpenGL, and I have a question about devicecontexts.

I’m using Delphi to create OpenGL windows on four different Devicecontexts, resulting in four different viewports. The creation of the OpenGL windows is not a problem, as long as I am using seperate renderingcontexts. Each DC would have one RC assigned to it. Switching between OpenGL windows is accomplished by ‘wglMakeCurrent()’. Ok, untill here no problems.

As I started to expand my application and tried to add textures to the OpenGL objects I noticed something unpleasant. It seems that the instruction ‘glTexImage2D’ creates a texture, but only to the devicecontext and rendering context currently active. It’s possible to load all the textures four times, once for every rendering context. However, this doesn’t seem to be a very efficient way, since all textures would be loaded 4x in memory.

So my question is: Is it possible to create one Rendering context, load all the relevant 3D- and texturedata to this RC, and output this to four different devicecontexts??? And how would I do this?

You look for wglShareLists.
It allows to share names of OpenGL objects among rendering contexts of the same pixelformat (or relaxed: OpenGL implementation).
It shares display lists, texture objects, and some more name spaces (vertex programs etc).
Call it after you have created your rendering contexts and before downloading textures. It doesn’t matter in which context you download, all share the same texture object.

Thanx for the reply! I am gonna try that one! I’ll let you know if it works

Allright, this seems to be working quite fine. However, there is one thing I noticed.

The following code is used to load my texture into memory:

glGenTextures(1, Texture);
glBindTexture(GL_TEXTURE_2D, Texture);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL); {Texture does NOT blend with object background}
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
gluBuild2DMipmaps(GL_TEXTURE_2D, 3, Width, Height, GL_RGB, GL_UNSIGNED_BYTE, pData);

When using ‘wglShareLists’ I need to call these instructions only once for each texture. Everything seems te be working fine accept for the third line. The RCs receiving the shared data seem to forget the ‘GLDECAL’ option. Is this normal? Am I forgetting something? Or should I just reapply all the selected options to all the RCs after loading the textures?

glTexParameteri changes the texture object itself, glTexEnvi doesn’t. It changes the application of textures (i.e. TexEnv modifies all texturing, not only the rendering of the currently bound texture object).

That’s why it’s not shared. You must respecify render states that aren’t contained in the shared objects for each rendering context.

But I’m curious. What are you trying to do? Perhaps, if your goal is a CAD-like multiple view application, multiple rendering contexts (and all related confusion) aren’t even necessary. You can ‘divide’ a rendering context by other means, such as glScissor and/or glViewPort.

If you’re going to share everything among your views, this is going to be far easier than multiple contexts.

I am working on a 3D editor that uses 4 different viewports on different devicecontexts. I can’t use one DC with four viewports applied to it, because the viewports need to remain seperate of eachother (seperate objects in application). However, I am curious about this GLscissor function. What does it exactly do? Is it possible to use only one RC with different DC’s with this function?

glScissor applies only to one rendering context. It’s not possible to have multiple device contexts and only one rendering context, so the answer is no.

glScissor clips geometry to a rectangular subregion of the current viewport.

The viewport selects a rectangular subregion of the current window for rendering. It also changes the mapping from clip space to window space, so you can keep using your ‘normal’ projection matrix and things will still look right. This isn’t the case with glScissor; it will simply cut off fragments. Your “projection center” or whatever you’d like to call it will still stay where it was, most likely the center of the overall window, not the center of the scissor rectangle.

However, when only using glViewPort, there is a potential problem. Read about it here (it’s #10: "The Viewport Does Not Clip or Scissor") .