Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6285026

OGL: shared context is problematic in multiscreen environments

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • 6
    • 5.0
    • client-libs
    • 2d
    • beta
    • 5.0
    • b45
    • generic
    • solaris_9

      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

            campbell Christopher Campbell (Inactive)
            campbell Christopher Campbell (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: