Jogl - No explicit glSwapBuffers & glEnd oddity

OpenGL Development JOGL Development
#1

Either I’m just being blind, or this method seems to be hidden :frowning: I’m guessing that the underlying Canvas likes to take care of this, but its not totally obvious.

I’m unsure of how the Animator class is actually useful - it seems to perform some voodoo with gldrawable.setNoAutoRedrawMode() to get a screen repaint, but I’m not sure. And i’m uneasy with letting the Animator control my main game loop - especially if i want to use Swing at the same time, its not obvious how best to use the two together.

Anyone else had a look at this?

Edit: Have a shufti at this:

public void display(GLDrawable canvas)
{
  // some setup
  gl.glBegin(GL.GL_LINES);
  {
    // some line drawing
  }
  gl.glEnd();
}

Doesn’t work :frowning: I tinkered around with matrix setups and a whole bunch of other initialisation, but to no avail. After looking at the Gears demo, I spot:

      //      gl.glEnd(); // DELIBERATE ERROR!

At the end of the drawing method. Commenting out my own glEnd produces the right output :o What on earth is going on here? ???

#2

Oops! That commented-out “deliberate error” glEnd oddity is some debugging code I left in when I was testing the DebugGL component of the composable pipeline. What I was doing there was doing two glEnd() calls in a row, which is illegal, and making sure that DebugGL caught that error.

That call is commented out in the demo, and can safely be ignored (it should be removed from the Gears demo).

As for glSwapBuffers(), you are correct – this is handled automatically by the GLCanvas and GLJPanel classes. The reason is that there is no need to expose these calls, and by not exposing them we can both hide all the platform-dependent special case code for window system interactions, and and also ensure that AWT/Swing threading issues are handled correctly.

You can definitely drive your demos without using the Animator. We have several demos that do this (by doing essentially the same work that the Animator does) , but I do not think that they are available online yet. I know some people at Sun are working hard to get these available ASAP.

-chris

#3

So, whats the replacement in the canvas for glSwapBuffers? As I mentioned the Animator seems to manage some voodoo with noAutoRedraw toggling on and off, and i can’t figure out why this causes the behaviour it does.

#4

SwapBuffers is called automatically after the display() method in your GLEventListener returns.

Producing documentation for this and other semantics in the library is a high priority, but the highest priority right now is getting the sources for the demos we ported for JavaOne online.

-Ken

#5

OT-

[quote]I’m unsure of how the Animator class is actually useful - it seems to perform some voodoo with gldrawable.setNoAutoRedrawMode() to get a screen repaint, but I’m not sure.
[/quote]
Yea, I splunked thru JOGL to figure out how it worked. The GLCanvas class has “autosense” threading technology so that it will always correctly use the underlying OpenGL context. That means it’ll behave correctly when driven by the main thread (e.g. when components are painted before the AWT thread kicks off), the AWT thread (e.g. a reshape event), or an outside thread like the Animator.