Using GL outside listener

OpenGL Development JOGL Development
#1

New to JOGL and have a simple question. It’s well documented that you’re not supposed to use getGL() outside of any GLEventListener method. I’m curious how I would go about updating textures, etc. in a multi-threaded app without having this ability.

I have a bunch of GLCanvases that I update with an array of pixels every second. Under Java2D I would just have an update( float[] pixels ) method that would insert the pixels into an offscreen image (and then a repaint() ) but with JOGL I can’t do:

public void update( float[] pixels ) {
myCanvas.getGL().glTexSubImage2D( ) <-- pass in pixels to update texture here
}

Hopefully this is clear enough. I’m sure this is a common situation but it’s not clear to me how to do it with JOGL. Help would be great appreciated.

#2

hi icm9768,

there are usually two aproaches to multithreaded gl,

  1. synchronize to your resources and render

  2. or update gl in a second gl context and render as usual with first context

//gl rendering thread
render(GL gl) {
   
  // gl.*...

  synchronized(pixels) {
    gl.glTex....(...pixels...)
  }
}

//uptate/worker/physics thread
updateTick() {

   int[] mypixels...;
  //do something cpu intensive with mypixels

  // performance critical section
  synchronized(pixels) {
    //copy mypixels to pixels
  }
}

or
2.
-init two gl contexts (e.g one Canvas, one 1x1pixel Pixelpuffer Context)
-render with canvas and update texture in the rendering thread of the pixelpuffer context

[edit] forgot to mention that OpenGL does not support multithreading by definition (it is a state machine, which is more or less a show stopper regarding multithreading). Thats why you cant just call gl.* of the same context from different threads.

#3

I usually use an action queue for injecting off-render-thread changes into the render thread: http://www.java-gaming.org/index.php?topic=12475.msg99927#msg99927

#4

concurrent queues are the more advanced version of a synchronized block of course :stuck_out_tongue:

cylab is right, queues are the better pattern to do real concurrent rendering. But i would recommend to implement them with fixed size and let them block on overflow since halting the rendering thread or slowdowns could cause problems ;D
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ArrayBlockingQueue.html

#5

Thanks for the replies. Makes good sense. The application I have in mind will have a number of GLCanvases (sharing the same GLContext), each responsible for rendering a given texture. The singleton framework you provided would work in this situation (correct me if I’m wrong) but it wouldn’t if I had multiple GL contexts adding to the queue?

That is to say that unless I provide a common GLContext to each GLCanvas in the constructor, each panel would have a unique GL, and if I added to the queue with the different GL objects, it’s likely that only one of the different GL’s in the queue would be current.

#6

The singleton was just for the simplicity in typical game like applications. You need of course create multiple instances of the queue, if you need to support different rendering targets.