Package com.jogamp.opengl

Interface GLSharedContextSetter

  • All Superinterfaces:
    GLAutoDrawable, GLDrawable, NativeSurfaceHolder
    All Known Subinterfaces:
    GLOffscreenAutoDrawable, GLOffscreenAutoDrawable.FBO
    All Known Implementing Classes:
    jogamp.opengl.GLAutoDrawableBase, GLAutoDrawableDelegate, GLCanvas, GLCanvas, GLJPanel
    public interface GLSharedContextSetter
extends GLAutoDrawable
    Adds capabilities to set a shared GLContext directly or via an GLAutoDrawable.

    Sharing of server-side OpenGL objects such as buffer objects, e.g. VBOs, and textures among OpenGL contexts is supported with this interface.

    A master GLContext is the GLContext which is created first. Subsequent shared GLContext w/ the master are referred as slave GLContext.

    Implementations of this interface control the slave's GLContext and GLAutoDrawable realization, i.e. the slave GLAutoDrawable will not be realized before their associated master.

    Using the nearest or same visual ID or caps across the shared GLDrawables will yield best compatibility.

    Lifecycle Considerations

    After shared objects are created on the master, the OpenGL pipeline might need to be synchronized w/ the slaves, e.g. via GL.glFinish(). At least this has been experienced w/ OSX 10.9.

    In general, destroying a master GLContext before their shared slaves shall be permissible, i.e. the OpenGL driver needs to handle pending destruction of shared resources. This is confirmed to work properly on most platform/driver combinations, see unit test com.jogamp.opengl.test.junit.jogl.acore.TestSharedContextVBOES2NEWT3 and similar.

    However, to avoid scenarios with buggy drivers, users may not destroy the master GLContext before its shared slave GLContext instances as long as they are using them.
    Otherwise the OpenGL driver may crash w/ SIGSEGV, due to using already destroyed shared resources, if not handling the pending destruction of the latter!
    Either proper lifecycle synchronization is implemented, e.g. by notifying the slaves about the loss of the shared resources, or the slaves validate whether the resources are still valid.

    To simplify above lifecycle issues, one may use a dummy GLDrawable and it's GLContext as the master of all shared slave GLContext. Since this dummy instance does not depend on any native windowing system, it can be controlled easily w/o being in sight.
    Below code creates a GLAutoDrawable based on a dummy GLDrawable: 

            // GLProfile and GLCapabilities should be equal across all shared GL drawable/context.
        final GLCapabilitiesImmutable caps = ... ;
        final GLProfile glp = caps.getGLProfile();
        ..
        final boolean createNewDevice = true; // use 'own' display device!
        final GLAutoDrawable sharedDrawable = GLDrawableFactory.getFactory(glp).createDummyAutoDrawable(null, createNewDevice, caps, null);
        sharedDrawable.display(); // triggers GLContext object creation and native realization.
        ...
        // Later a shared 'slave' can be created e.g.:
        GLWindow glad = GLWindow.create(caps); // or any other GLAutoDrawable supporting GLSharedContextSetter
        glad.setSharedAutoDrawable(sharedDrawable);
        glad.addGLEventListener(..);
        glad.setVisible(true); // GLWindow creation ..

    GL Object Synchronization

    Usually synchronization of shared GL objects should not be required, if the shared GL objects are created and immutable before concurrent usage.

    However, using drivers exposing GLRendererQuirks.NeedSharedObjectSync always require the user to synchronize access of shared GL objects.

    Synchronization can be avoided if accessing the shared GL objects exclusively via a queue or Ringbuffer, see GLMediaPlayerImpl as an example.

    Known Driver Issues
    Intel's Mesa >= 9.1.2 Backend for [Sandybridge/Ivybridge] on GNU/Linux 

     Error: 'intel_do_flush_locked: No such file or directory'
 JogAmp: https://jogamp.org/bugzilla/show_bug.cgi?id=873
 freedesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=41736#c8
    Shared context seems not to be supported w/ lock-free bound X11 display connections per OpenGL drawable/context. The error message above is thrown in this case. Hence the driver bug renders shared context use w/ JOGL impossible.

    Hisilicon's Immersion.16 on Android

    We failed to create a shared ES2 context on another thread.