converting from Sun's jogl to jogamp's jogl -- HELP

I have a large application that uses Sun's old jogl. It has multiple GLCanvases in a multi-panel display.  The app shows a  
volume rendered view in one panel, and three orthogonal views below in three different panels. Each has a different GLCanvas. The GLCanvases share texture memory, vertex buffer memory, index buffer memory, shaders on the GPU. I also use multiple framebuffers for the volume rendering and displaying multiple semi-transparent surfaces.

When I try to convert to jogamp's jogl (using the latest release build). The shared context breaks -- either I get an exception or just a black window. The exception is something like 'trying to use GL with a context that didn't create it'. The shared context is essential to my application since everything I display shares the same textures, vertex buffers, etc.

I tried creating a pbuffer to store the shared context (based on an earlier post), but this didn't work for the window that uses the framebuffer for volume rendering or for multiple semi-transparent surfaces.

I tried NEWT but there doesn't seem to be a way to put the GLWindow into a multi-panel display.

So is there a way to do what I used to do with Sun's jogl? Shared contexts, multiple GLCanvases or GLWindows in a multi-panel display.

Please help -- I'm about to give up on jogamp.

Hi Alexandra,

Do you have a small test case you could give us? I know it may be difficult to chop out a small piece of your app and make it stand alone as a test, but this would give us the best chance of tracking down this bug. Otherwise, we'd have to just start writing stuff at random and see if we could get it to break, which is not very feasible for a small open-source team.

We also need to know the usual info that comes with a bug report: versions of Java, OS, platform, video card, driver version, and the pasted text of the stack trace you get when it errors out.

Thanks for your help, and sorry for the difficulties you're encountering during our pre-release period

Thanks for replying.  It's not easy for me to carve out a portion of the code. I did modify this program:

http://jogamp.org/git/?p=jogl.git;a=blob;f=src/junit/com/jogamp/test/junit/jogl/acore/TestSharedContextListAWT.java;h=b44158dce98537b7e12e4a354a702d0082f2b4ef;hb=de2a30104098216963132ed02b3dd66acd799d9e

And instead of Gears put in part of my program to test. I got the shared context to work. But when I go back to my main app, and follow the same code initialization I now get this error:

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: No OpenGL context is current on this thread
        at javax.media.opengl.DebugGL2.checkContext(DebugGL2.java:32463)
        at javax.media.opengl.DebugGL2.glDeleteBuffers(DebugGL2.java:13932)

I think the problem is that I am using the mouse to drag in one canvas, which sends a message to my 'main' display which then tries to update the objects/memory on the GPU.  But I'm not really sure. I will try to separate out the code and put it in the above 'TestShared...' and send it to you to help debug.

I'm using jogamp 2.0-rc2 build, on a Windows XP machine with NVIDIA Quadro FX 4800, driver 190.38 (I can't update my driver because then framebuffers completely stop working).

What's frustrating is that my app works with Sun's old jogl.  It's only when I update to jogamp that it breaks.

I do appreciate the help!

I'm also getting this error when I try to implement the shared context in my application.

Caused by: javax.media.opengl.GLException: This GL object is being incorrectly used with a different GLContext than that which created it
        at javax.media.opengl.DebugGL2.checkContext(DebugGL2.java:32466)
        at javax.media.opengl.DebugGL2.glBindTexture(DebugGL2.java:15270)
        at WildMagic.LibRenderers.OpenGLRenderer.OpenGLFrameBuffer.Enable(OpenGLFrameBuffer.java:166)

Shared contexts seem to only work for me with very simple examples. Not when I use the framebuffer for render-to-texture or for translucent surfaces.

Again, in Sun's jogl this all worked perfectly. The application code hasn't changed -- it's the underlying jogl implementation that changed.  I would like to use jogamp so I can use jocl...

Thanks again.

On Wednesday, March 23, 2011 20:43:14 Alexandra [via jogamp] wrote:
The GLContext is not [guaranteed to be] current when invoking your input event listener.

However you handle your 'signal' which uses GL (deleteBuffers),
you have to ensure it operates within a current GLContext.

Either you encapsulate your code like this:
  if( GLContext.NOT_CURRENT <= ctx.makeCurrent()) {
        fail;
  }
  try {
      gl.do_something
  } finalize {
     ctx.releaseContext();
  }

Or you invoke a GLRunnable on your GLAutoDrawable instance (GLCanvas, GLWindow, ..):

http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GLRunnable.html
http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GLAutoDrawable.html#invoke%28boolean,%20javax.media.opengl.GLRunnable%29

~Sven

>
> I'm using jogamp 2.0-rc2 build, on a Windows XP machine with NVIDIA Quadro
> FX 4800, driver 190.38 (I can't update my driver because then framebuffers
> completely stop working).
>
> What's frustrating is that my app works with Sun's old jogl.  It's only when
> I update to jogamp that it breaks.
>
> I do appreciate the help!

I concur with Wades statement, as I made it many time - sorry for nagging :)
Please follow bugreport instructions:
  http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing

Of course - we save both our patience, time and miscommunication,
if you provide a little [unit] test - you know the drill :)

BTW - I remember the FBObject bug now, I guess I lost this 'task' :(
If it was you - can you resend me the informations you once provided ?
This is another example why using bugzilla besides these emails is a good thing.

Sorry, didn't mean to scold you - just trying to convince my fellow colleagues
to our tiny little process :)

Cheers, Sven

So I thought that maybe the problem was I was calling glDeleteBuffers from the mouseDragged function and the GLContext might only be current in the init( GLAutoDrawable ) or display( GLAutoDrawable ) functions. So I delayed calling glDeleteBuffers until the display() function... Here's my new exception:

Caused by: javax.media.opengl.GLException: This GL object is being incorrectly used with a different GLContext than that which created it
        at javax.media.opengl.DebugGL2.checkContext(DebugGL2.java:32466)
        at javax.media.opengl.DebugGL2.glDeleteBuffers(DebugGL2.java:13932)


Any ideas?

I think the problem is with shared contexts where the shared vertex buffer is modified, the shared texture is deleted then reloaded.  When I call glTexSubImage to modify a shared texture it works. But if I want to swap out a shared texture completely I get an error.

This worked with Sun's JOGL so I think this is a jogamp bug.

Hi Alexandra,

Your bug sounds tricky enough that I doubt we can figure it out just by messaging text back and forth -- we need code

If you can give us a small standalone test that shows the bug (it can even just be one page, like the ones at http://jogamp.org/wiki/index.php/Using_JOGL_in_AWT_SWT_and_Swing), then I can pretty much guarantee that we can fix it. I'm completely willing to believe we have a bug in JOGL 2 -- you don't have to convince me!

We just need the code to duplicate your bug, otherwise we could search for weeks and not find it (and in the meantime other important bugs might not get fixed).

I saw somewhere else that the following exception:

Caused by: javax.media.opengl.GLException: This GL object is being incorrectly used with a different GLContext than that which created it

might be caused by caching the GL. So every time I get the init(GLAutoDrawable) or display(GLAutoDrawable) I do

myGL2 = auto.getGL().getGL2();

Anyway... how would I use the DebugGL2 in this case? Where do I call:

GLAutoDrawable setGL( new DebugGL2( auto.getGL().getGL2() ) )

I currently need the DebugGL2 for the framebuffer implementation of translucent surfaces to work...

I keep overlapping posts with you all...

I will make a demo and post it for you to test.

Tomorrow!

Thanks -- I do appreciate the help!