Can I setRenderingThread(AWT-EventQueue-Thread)?

I have read Jogl - User’s Guide, which says
It is generally recommended that applications perform as little work as possible inside their mouse and keyboard handlers to keep the GUI responsive. However, since OpenGL commands can not be run from directly within the mouse or keyboard event listener, the best practice is to store off state when the listener is entered and retrieve this state during the next call to GLEventListener.display().

I’m wondering what is the disadvantage if I write code like following. What is the proper way to render in “repaint only on demand” mode? I also want to know is there any boost in performance if I turn on switch “-DJOGL_SINGLE_THREADED_WORKAROUND=true”?

Thanks

///////////////////////// code ////////////////////////
import static net.java.games.jogl.GL.;
import net.java.games.jogl.
;
import net.java.games.jogl.util.BufferUtils;

import javax.swing.;
import java.awt.
;
import java.awt.event.MouseListener;
import java.awt.event.MouseEvent;
import java.awt.event.ComponentAdapter;
import java.awt.event.ComponentEvent;
import java.nio.IntBuffer;

public class Test extends JFrame implements GLEventListener, MouseListener {

GLCanvas canvas;
GL gl;
GLU glu;

public Test() throws HeadlessException {
canvas = GLDrawableFactory.getFactory().createGLCanvas(new GLCapabilities());
gl = canvas.getGL();
glu = canvas.getGLU();
canvas.addGLEventListener(Test.this);
canvas.addMouseListener(Test.this);
add(canvas);
addComponentListener(new ComponentAdapter() {
public void componentShown(ComponentEvent e) {
System.out.println(Thread.currentThread());
canvas.setRenderingThread(Thread.currentThread());
}
});
}

public static void main(String[] args) {
Test t = new Test();
t.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
t.setSize(640, 480);
t.setLocationRelativeTo(null);
t.setVisible(true);
}

private void processHits(int hits, IntBuffer buffer) {
System.out.println(“hits = " + hits);
int ptr = 0;
for(int i=0; i<hits; i++) {
int names = buffer.get(ptr);
System.out.println(” number of names for hit = " + names); ptr++;
System.out.println(" z1 is " + (float)buffer.get(ptr)/0x7fffffff + “;”); ptr++;
System.out.println(" z2 is " + (float)buffer.get(ptr)/0x7fffffff + “;”); ptr++;
System.out.print(" names are ");
int ii = 0, jj = 0;
for(int j=0; j<names; j++) {
System.out.print(buffer.get(ptr));
if(j==0) ii = buffer.get(ptr);
else if(j==1) jj = buffer.get(ptr);
ptr++;
}
System.out.println();
board[ii][jj] = (board[ii][jj]+1)%3;
}
}

final int BUFSIZE = 512;

private int[][] board = new int[3][3];

public void init(GLDrawable glDrawable) {
gl.glClearColor(0f, 0f, 0f, 0f);
}

private void drawSquares(int mode) {
for(int i=0; i<3; i++) {
if(mode==GL_SELECT) gl.glLoadName(i);
for(int j=0; j<3; j++) {
if(mode==GL_SELECT) gl.glPushName(j);
gl.glColor3f((float)i/3, (float)j/3, (float)board[i][j]/3);
gl.glRecti(i, j, i+1, j+1);
if(mode==GL_SELECT) gl.glPopName();
}
}
}

public void display(GLDrawable glDrawable) {
gl.glClear(GL_COLOR_BUFFER_BIT);
drawSquares(GL_RENDER);
gl.glFlush();
}

public void reshape(GLDrawable glDrawable, int x, int y, int w, int h) {
gl.glViewport(0, 0, w, h);
gl.glMatrixMode(GL_PROJECTION);
gl.glLoadIdentity();
glu.gluOrtho2D(0, 3, 0, 3);
gl.glMatrixMode(GL_MODELVIEW);
gl.glLoadIdentity();
}

public void displayChanged(GLDrawable glDrawable, boolean b, boolean b1) {}

public void mousePressed(MouseEvent e) {
IntBuffer selectBuf = BufferUtils.newIntBuffer(BUFSIZE);
int[] viewport = new int[4];
gl.glGetIntegerv(GL_VIEWPORT, viewport);

gl.glSelectBuffer(BUFSIZE, selectBuf);
gl.glRenderMode(GL_SELECT);

gl.glInitNames();
gl.glPushName(0);

gl.glMatrixMode(GL_PROJECTION);
gl.glPushMatrix();
gl.glLoadIdentity();
glu.gluPickMatrix(e.getX(), viewport[3]-e.getY(), 5, 5, viewport);
glu.gluOrtho2D(0, 3, 0, 3);
drawSquares(GL_SELECT);

gl.glMatrixMode(GL_PROJECTION);
gl.glPopMatrix();
gl.glFlush();

int hits = gl.glRenderMode(GL_RENDER);
processHits(hits, selectBuf);
canvas.repaint();

}

public void mouseClicked(MouseEvent e) {}
public void mouseReleased(MouseEvent e) {}
public void mouseEntered(MouseEvent e) {}
public void mouseExited(MouseEvent e) {}
}

Not recommended and not portable. If the AWT or Java2D use OpenGL internally, you will interfere with their rendering and they will blow away your current OpenGL context on the AWT EventQueue thread.

Got it!
Thank you Ken :slight_smile:

I would like to ask a potentially silly question on this topic.

How does JOGL prevent another process from blowing away its OpenGL context? By other process, I don’t just mean AWT or JFC/Swing, but also possibly an OS process outside of Java that paints in OpenGL.

After all, the JOGL rendering thread’s processing may be interspersed by other OpenGL rendering processes (I assume that the rendering thread doesn’t hog the CPU… or GPU I gues…).

OpenGL contexts are process-local.

OpenGL contexts are process-local

Thanks so far; you’ve taken some of the confusion away for me. Now I understand that other OS processes cannot mess around with the JOGL OpenGL context, because they have their own.

There’s one thing I’m still curious about. I’m not saying that it’s a good idea, but for argument’s sake, suppose that I would create a Runnable that renders continuously.

If it lives in its own thread, I expect that my Runnable is going to get its OpenGL context clobbered as described in your first reply. What if it lives in the AWT/SWT/Swing painting thread? Is there any chance of AWT/SWT/Swing still interrupting my Runnable or is it going to freeze thanks to my Runnable hogging the processor?

I suspect that it will freeze, but I would appreciate it if you could verify my assumptions. If it does freeze, I’m thinking that creating a different process with no AWT/SWT/Swing components is a good way to achieve full-screen, exclusive rendering (unless there’s an easier way).

[quote]There’s one thing I’m still curious about. I’m not saying that it’s a good idea, but for argument’s sake, suppose that I would create a Runnable that renders continuously.

If it lives in its own thread, I expect that my Runnable is going to get its OpenGL context clobbered as described in your first reply. What if it lives in the AWT/SWT/Swing painting thread? Is there any chance of AWT/SWT/Swing still interrupting my Runnable or is it going to freeze thanks to my Runnable hogging the processor?

I suspect that it will freeze, but I would appreciate it if you could verify my assumptions. If it does freeze, I’m thinking that creating a different process with no AWT/SWT/Swing components is a good way to achieve full-screen, exclusive rendering (unless there’s an easier way).
[/quote]
There are two things to consider here. First, JOGL’s OpenGL contexts are not (currently) shared with any other rendering system like Java2D, so it is fine to make a JOGL context current on a given thread and render continuously into it. This is done in most of the JOGL demos via the Animator class and the setRenderingThread optimization. However, OpenGL states that only one context can be current on a given thread at any given time, so if Java2D decides to make some other OpenGL context current on the AWT event queue thread, it will blow away the OpenGL context JOGL has made current on that thread. This is one of the reasons why you should only perform rendering in a vary localized fashion in your GLEventListener’s display() method; it allows better interoperation with the AWT and Java2D. You are effectively painting your GLCanvas object using raw OpenGL rather than Java2D, and this works fine as long as you don’t expect your OpenGL context to remain current outside of the context of your GLEventListener’s display() and other methods.

Thanks for the information (and sorry about a rather late reply; I’ve been -and still am- ploughing through JNI problems in Eclipse).

If I understand correctly, any thread that isn’t subject to AWT/SWT/Swing rendering can safely rely on an OpenGL context remaining intact. This is quite interesting for a threadpool experiment I’m planning (if J2SE 5.0 is ever going to run my DLL that is).