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.