-
Bug
-
Resolution: Fixed
-
P4
-
5.0
Currently in the OGL pipeline we have the concept of the "shared context". When
we initialize the OGL pipeline for the first time, we create a GLXContext (or
HGLRC on Windows). This shared context is used for two purposes. First, when
other contexts are created, we use the shared context as a way to share texture
objects. For example, a context that shares its lists with another context can
refer to the first context's texture objects and vice versa.
Secondly, there are a number of situations in which we are not necessarily
rendering directly to an OpenGL surface, but we need to access a texture object.
For example, when we cache an image in an OpenGL texture object, we don't have
a reference to a destination surface, and therefore we may not have a current
context (and one cannot make OGL calls like glTexImage2D() without first having
a current context). Another example would be when disposing resources such as
a texture object, we may not have a current context. So to combat this, we use
the same "shared context" described above and make it current before performing
any of the aforementioned operations.
I've never been a big fan of this solution, but it has mostly worked. But it is
apparent that this solution breaks down somewhat in multiscreen environments.
Imagine one machine with two video boards, one supports the
GL_ARB_texture_non_power_of_two extension, but the other does not. Now imagine
the shared context was created using the characteristics of the first display.
When we go to create a texture object for the first display, we make the shared
context current, and then try to create a non-pow2 texture. This will work for
the first display that supports that extension, but this won't work for the
second display since it doesn't support the necessary extension.
This is just one example where using the shared context can cause problems. In
the future when we support the GL_EXT_framebuffer_object extension, a similar
problem will arise if one device supports FBO but the other does not. In fact,
the reason I filed this bug is because I think it should be fixed before we
integrate the FBO changes, and the proposed fix will also make it easier to
add FBO support.
###@###.### 2005-06-14 02:41:55 GMT
we initialize the OGL pipeline for the first time, we create a GLXContext (or
HGLRC on Windows). This shared context is used for two purposes. First, when
other contexts are created, we use the shared context as a way to share texture
objects. For example, a context that shares its lists with another context can
refer to the first context's texture objects and vice versa.
Secondly, there are a number of situations in which we are not necessarily
rendering directly to an OpenGL surface, but we need to access a texture object.
For example, when we cache an image in an OpenGL texture object, we don't have
a reference to a destination surface, and therefore we may not have a current
context (and one cannot make OGL calls like glTexImage2D() without first having
a current context). Another example would be when disposing resources such as
a texture object, we may not have a current context. So to combat this, we use
the same "shared context" described above and make it current before performing
any of the aforementioned operations.
I've never been a big fan of this solution, but it has mostly worked. But it is
apparent that this solution breaks down somewhat in multiscreen environments.
Imagine one machine with two video boards, one supports the
GL_ARB_texture_non_power_of_two extension, but the other does not. Now imagine
the shared context was created using the characteristics of the first display.
When we go to create a texture object for the first display, we make the shared
context current, and then try to create a non-pow2 texture. This will work for
the first display that supports that extension, but this won't work for the
second display since it doesn't support the necessary extension.
This is just one example where using the shared context can cause problems. In
the future when we support the GL_EXT_framebuffer_object extension, a similar
problem will arise if one device supports FBO but the other does not. In fact,
the reason I filed this bug is because I think it should be fixed before we
integrate the FBO changes, and the proposed fix will also make it easier to
add FBO support.
###@###.### 2005-06-14 02:41:55 GMT