Context sharing: regression from JSR231 to Jogl 2.x?

Has anything changed in Jogl2 regarding context sharing between different drawables? Code that I wrote against the JSR-231 builds of Jogl no longer works after upgrading to Jogl2 RC2. For instance, I would expect that after creating two GLCanvases as below, texture objects created in the first would also be valid in the second. This was the case with older versions but not with Jogl2. Do I need to adapt my code or is this a bug?

    fFrame = new JFrame();
    fFrame.getContentPane().setLayout( new GridLayout( 1, 2 ) );

    fFrame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );

    fDrawable1 = new GLCanvas( new GLCapabilities( GLProfile.getDefault() ) );
    fDrawable1.setSize( 512, 512 );
    fFrame.getContentPane().add( fDrawable1 );

    fDrawable2 = new GLCanvas( new GLCapabilities( GLProfile.getDefault() ), fDrawable1.getContext() );
    fDrawable2.setSize( 512, 512 );
    fFrame.getContentPane().add( fDrawable2 );

    fFrame.pack();
    fFrame.setVisible( true );

Thanks,
-- Tom

Hi!

Something has changed in the way the context is handled, more precisely on when it is available. It is not a regression as it fixes several bugs and it clarifies the way the reparenting should work.

In JOGL 1.1.1a, you could get the context of a GLCanvas as soon as the instance had been created (like in your example).

In JOGL 2.0, you can get the context for the first time only once the method addNotify() has been called. You can override this method like I did in Ardor3D or you can try to get the context later. This is not a bug.

On Tuesday, September 13, 2011 03:06:54 PM gouessej [via jogamp] wrote:
Yes. You can also use the GLEventListener init(..) method,
called after GLContext creation.

~Sven

You're right, it is the best solution as you're sure to have a current OpenGL context.

Thanks for the feedback, guys. Changing the order of operations as you suggested makes the context sharing work, but I still have a crucial problem that I didn't have with Jogl 1.1.1.

Allow me to elaborate on what I'm trying to achieve. I use a GLCanvas as my main drawable. The application uses a docking framework and offers a full-screen mode, both of which trigger changes to the component hierarchy surrounding the GLCanvas. By default, these changes cause all my application's texture objects to be lost due to the GL context being recreated. I successfully circumvented this with Jogl 1.1.1 by creating a pbuffer that shares its context with the GLCanvas. Since the pbuffer is not affected by the component hierarchy changes, it "protects" my texture objects for me.

My current status with Jogl 2.x is that texture objects are valid in both the canvas and the pbuffer as long as I leave the canvas where it is. When the canvas reinitializes its context, however, it looks like the context sharing with the pbuffer is broken, and as a result my textures are still gone. Am I missing anything else?

If it helps, here's the unit test code that I'm using to investigate these issues:
GLCanvasContextSharingFullscreenTest.java

Thanks again,
-- Tom

On Wednesday, September 14, 2011 12:35:28 PM TomN [via jogamp] wrote:
Same as in unit test (line ~30 initShared())
  http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/acore/TestSharedContextVBOES2NEWT.java;h=a37c43c58b6003eb838f93179f6af3c62547915d;hb=HEAD

The above one uses shared VBO names, another test validates display lists (the ole gears).

>
> My current status with Jogl 2.x is that texture objects are valid in both
> the canvas and the pbuffer as long as I leave the canvas where it is. When
> the canvas reinitializes its context, however, it looks like the context
> sharing with the pbuffer is broken, and as a result my textures are still
> gone. Am I missing anything else?

Looks like some bug somewhere, yup.

>
> If it helps, here's the unit test code that I'm using to investigate these
> issues:
> http://forum.jogamp.org/file/n3335436/GLCanvasContextSharingFullscreenTest.java
> GLCanvasContextSharingFullscreenTest.java

Indeed it helps, thank you.

Your understanding of 'sharing' a context is just a bit wrong here.

A shared context must be registered at the GLAutoDrawable _before_ it's GLContext is
being created. It has to be this way, since you need to create the native context
while passing the shared one as an argument to make it share the shared one :)
(sorry for the complicated language)

As shown here:
  http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/acore/TestSharedContextVBOES2NEWT.java;h=a37c43c58b6003eb838f93179f6af3c62547915d;hb=HEAD#l84

  http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/acore/TestSharedContextListAWT.java;h=99e81af04b6eec8fec375aee979afe3c7fe2c544;hb=HEAD#l88

The internal GLContextImpl constructor:
  http://jogamp.org/git/?p=jogl.git;a=blob;f=src/jogl/classes/jogamp/opengl/GLContextImpl.java;h=c3fcc50571f977fb2dada251233d8e0d788c9015;hb=HEAD#l115

Hope this helps.

I would recommend the following:

 - copy the above 'AWT Shared' unit test
 - apply your texture functionality test to it
 - test it .. and pls send back that test, so we have one for textures

>
> Thanks again,
> -- Tom

You are very welcome

~Sven