Loading shaders possible outside of gleventlistener's init reshape display?

OpenGL Development JOGL Development
#1

I’ve got a shader working when I use the GLAutoDrawable parameter passed via the gleventlistener’s “init” / “reshape” / “display” methods.

However, if I take this parameter and store it and try to load a shader based on some other action like a button press, it doesn’t work - I have to wait and do it from within a “display” call.

I was wondering if anyone could shed some light on why it only works at those times? It’s buggin me.

Thanks in advance,

Wild Bill Kelso

#2

you must have active GLAutoDrawable context ,without it loading any shader fails, you probably can not just store it (i may be wrong ), in example of cg use in
jogl: ogl-demos-src 2005-12-06\jogl-demos\src\demos\cg\runtime_ogl\cgGL_vertex_example.java you can find some intresting comment:

public void init(GLAutoDrawable drawable) 
  {
    // Note: we initialize Cg in this init() method instead of main()
    // because Cg (apparently) requires an active OpenGL context in order to
    // initialize correctly (otherwise the CheckCgError() call after
    // cgGLLoadProgram() will fail).

without active context you will not be able to initalize or run any shaders, shaders are close to gpu so it is not suprising that Opengl context must be active

#3

As for the explanation
There are several multithreading constraints while communicating with OpenGL. For one there has to be a so called OpenGL “context” in a state that allows to call OpenGL functions.

JOGL handles this constraints by providing the GLEventListener callbacks. The JOGL framework ensures, that the given GL object can successfully call the native OpenGL functions for the time the GLEventListener interface methods are executed. This is the very reason why the GLAutoDrawable object is passed as the methods argument instead of providing a gobal “getGL()” method or something.

If you store the GL object you get in the GLEventListener method, there is a good chance, that the OpenGL context is not in the right state the next time you call a method on the GL object, so your call will fail. Best practice is, not to store the GL object and implement some kind of action queue to defer OpenGL calls to the display() method. I use a simple GLAction interface for that:


public interface GLAction
{
	public void execute(GL target);
}

and store instances of them in a GLQueue singleton:


public class GLQueue
{
	private static GLQueue instance = null;
	private final ArrayList queue= new ArrayList(16);

	protected GLQueue(){}

	public static synchronized GLQueue getInstance()
	{
		if(instance==null) instance= new GLQueue();
		return instance;
	}

	public void add(GLAction action)
	{
		synchronized (queue) { queue.add(action); }
	}

	public void execute(GL gl)
	{
		// make a copy of the queue to allow thread safe iteration
		ArrayList temp = null;
		synchronized (queue)
		{
			// Only make a copy, if the queue has entries
			if( queue.size() != 0 )
			{
				temp = new ArrayList(queue);
				queue.clear();
			}
		}

		// iterate outside of the synchronization to avoid blocking the queue
		if( temp!=null )
		{
			for (int i=0; i < temp.size();i++)
			{
				((GLAction) temp.get(i)).execute(gl);
			}
		}
	}
}

so each time, I have to react to a button-press or something I add it to the queue:


public void actionPerformed(ActionEvent event)
{
	GLQueue.getInstance().add(
		new GLAction()
		{
			public void execute(GL target)
			{
				// do something gl related
			}
		}
	)
}

and execute the queue in my display-method:


public void display(GLAutoDrawable drawable)
{
	GLQueue.getInstance().execute(drawable.getGL());
}

There are mechanisms in the new JSR version of JOGL to allow for more control over context and threading behaviour, but I suggest only to touch them, if you reach expert level or really have to for some reasons :wink: