Help please! Why this doesn't work???

OpenGL Development JOGL Development
#1

I’m having a ton of trouble trying to understand why I can not create a GLPbuffer at run-time, and call the display method on it. Everything works fine if I delete the call to the display method. It appears that JOGL is creating the GLPbuffer, but will not display it.

If I move the creation source code to the Init method of the GLEventListener then I can call the GLPbuffer.display method from another display method. But I can not create it in the display method. I don’t understand why?

Here is how to reproduce the problem.

I wanted to post the whole source code, but the text thing here says it’s to large.

So to reproduce this problem load gears.java from the JOGL demo’s, and insert the following source code at the top.

class c3dShadowCanvas implements GLEventListener {
    public void init(GLDrawable drawable) {
            drawable.setGL(new DebugGL(drawable.getGL()));
            GL gl = drawable.getGL();
            GLU glu = drawable.getGLU();
    }
    public void display(GLDrawable drawable) {
            GL gl = drawable.getGL();
            GLU glu = drawable.getGLU();
    }
    // Unused routines
    public void reshape(GLDrawable drawable, int x, int y, int width, int height) {}
    public void displayChanged(GLDrawable drawable, boolean modeChanged, boolean deviceChanged) {}
}

Add this somewhere in the GearRenderer class.

private int count=0;

Then down in the GearRenderer.display(GLDrawable drawable) method add these lines at the start of the method call.

        count++;
        if (count==10) {
            if (drawable.canCreateOffscreenDrawable()) {
                  // init pbuffer
                  GLCapabilities caps = new GLCapabilities();
                  caps.setDoubleBuffered( false );
                  GLPbuffer pbuffer = drawable.createOffscreenDrawable(caps, 200, 200 );
                  pbuffer.addGLEventListener(new c3dShadowCanvas());
                  pbuffer.display();
            }
        }

The reason I do this on frame 10 is not reason at all. I just want to demonstrate that I need to create the GLPbuffer at run-time, and can’t do it during initialization. This is because I never know if I will need the buffer, what size it will be, and how many I will need. It depends on parameters the user selects during run-time.

This is such a huge problem for me, and I’ve been trying to figure out what is going wrong with JOGL in the display method. I often get the “out of memory” error. If I debug this I find that the display method is called successfully, but the next future call to any GL method will cause an exception.

I’m braking something inside JOGL but I don’t know what.

#2

Ok, I figure I’ve come across a strange bug in JOGL. Further, I assume that this is a hard bug to figure out, and this is why I’m not seeing a lot of responces to it.

I would like to file this as a bug in JOGL, but I don’t know how to do that. Can someone provide me with a URL to submit the bug.

This is what I have figured out while looking at the JOGL source.

When GLPbuffer has its display() method called. This will trace down into the GLPbufferImpl.java file. Which will tell the context to perform two operations.

  1. The initailization of the buffer (mainly calling the Init method on the listener)
  2. The drawing of the buffer (mainly calling the display).

At this point I can not figure out why creating the GLPbuffer in a listener’s init method works, but creating one in a display metod doesn’t. From what I can tell there is something wrong with the context for the buffer that is created. Or something related to that effect.


                  GLPbuffer pbuffer = drawable.createOffscreenDrawable(caps, 200, 200 );
                  pbuffer.addGLEventListener(new c3dShadowCanvas());
                  System.out.println("1: " + pbuffer.isInitialized() );
                  pbuffer.display();
                  System.out.println("2: " + pbuffer.isInitialized() );

If I modify the above code I posted before to include reporting the initialized state of the buffer. I will see that the buffer is “false” before the display, and “false” afterwards.

Which means that the “InitAction” in GLPbufferImpl was never executed.

I think this fails to be called because inside GLContext.java there is a method that is called “makeCurrent”. Here is the docs from that method.

  /** Attempts to make the GL context current. If necessary, creates a
      context and calls the initAction once the context is current.
      Most error conditions cause an exception to be thrown, except
      for the case where the context can not be created because the
      component has not yet been visualized. In this case makeCurrent
      returns false and the caller should abort any OpenGL event
      processing and instead return immediately.  */
  protected abstract boolean makeCurrent(Runnable initAction) throws GLException;

This method will fail if the component has not yet been visualized.

“visualized” what the heck does that mean?

This is as far as I’ve got’n, and now I’m just confused.

Could someone explain what the term visualized means. Does this mean making the OpenGL context appear on the screen?

#3

This looks like a bug in the GLPbuffer implementation. You can use this as a workaround:


      count++;
      if (count==10) {
        if (drawable.canCreateOffscreenDrawable()) {
          // init pbuffer
          GLCapabilities caps = new GLCapabilities();
          caps.setDoubleBuffered( false );
          pbuffer = drawable.createOffscreenDrawable(caps, 200, 200 );
          pbuffer.addGLEventListener(new c3dShadowCanvas());
        }
      } 

      if (pbuffer != null && pbuffer.isInitialized()) {
        pbuffer.display();
      }

I think I see what is going wrong in the OpenGL context management and have filed Issue #143 to track it. Thanks for your test case.

#4

A fix for Issue 143 has been checked in. I’m not 100% confident of it but it definitely makes your test case work and doesn’t break any of the existing demos. It will be present in the next JOGL beta.

#5

Hi,

Thanks so much for fixing that bug for me!

Can I send you anything in return? Some $$ or a video game. You saved my ass at work. :slight_smile:

#6

No, that’s ok.