Posted by xghost on Jul 25, 2015; 9:35pm
URL: https://forum.jogamp.org/Can-JOGL-be-used-without-requiring-GLAutoDrawable-instances-tp4034953p4034970.html

Sven Gothel wrote

OK.
Just for the record, the GLAutoDrawable/GLEventListener 'assisted rendering'
paradigm is optional, even though it is recommended.
One can always use plain GLDrawable/GLContext etc. and handle the details
manually.

Hi Sven,

Can you elaborate on this a bit? I'm not sure I'm familiar with this way of using JOGL. Does this mean that I can do something along the following lines without needing to be inside one of the GLEventListener overrides or something?:

private void someMethodThatIsNotGLEventListenerDisplayOverride() {
	GL4 gl = GLContext.getGL().getGL4();
	gl.glUseProgram(...);
	// ... more arbitrary OpenGL calls, etc...
}

I mean, if it's something that would allow me to request and get a GL instance at arbitrary locations, then it seems to be what I'm looking for --at least if I'm understanding this correctly.

Sven Gothel wrote

You may confuse ShaderProgram w/ ShaderCode.
The latter merely holds the source code or binary code for one shader
and _can_ be instantiated w/o a GL instance.

The ShaderProgram class has the link(...) method, which requires a GL instance to be passed in. This is what I had in mind, but yes the thing is that when the class needs to perform OpenGL calls internally, it needs the GL instance, which is what I was trying to avoid in the public interface of my shader classes.

For example, when I instantiate one of my attributes (e.g. below), OpenGL calls need to be issued (at least with the current design):

program.createFloatInput("position_x", GpuShaderProgram.Input.Type.ATTRIBUTE);

It'll be expected to hold its own valid attribute ID. Since I already get the name, and the shader program itself is built, then this will (internally) result in an OpenGL call to glGetAttribLocation:

public Input<Float> createFloatInput(String name, Input.Type type) {
	switch (type) {
		case ATTRIBUTE:
			return new GLSLFloatProgramAttribute1(this, name);
		// ...
	}
}
// ....
GLSLFloatProgramAttribute1(GpuShaderProgram shader, String attributeName) {
	// ... 
	location = glGetAttribLocation(shader.getId(), attributeName);
	// ...
}

Normally, for this to happen a valid/non-cached GL instance would have to be made available somewhere here (e.g. publicly when the client wants to call the createFloatInput method above to allow the gl.glGetAttribLocation(...) call).

Something similar would be true when setting a value for the program input. For example, the line below would be expected to send the value for the GLSL vec4(1, 1, 1, 1) to the vertex program uniform, which would require an OpenGL call to glUniform4f in this case:

program.createVec4Input("frag_color", GpuShaderProgram.Input.Type.UNIFORM);
// ...
program.<Vec4> getInput("frag_color").set(Vec4f.createFrom(1f, 1f, 1f, 1f));
// ...
@Override
public void set(Vec4 v) {
	// setting the frag_color uniform input :)
	glUniform4f(location, v.getX(), v.getY(), v.getZ(), v.getW());
}

But for that, it'd also need a GL instance available.

Perhaps (fingers crossed) your previous suggestion to do things manually might allow me to accomplish/reach the intended goal. That being said, I'm also open to updating my code ofc.

Sven Gothel wrote

The ShaderCode and ShaderProgram does require the GL instance all of its
methods performing OpenGL operations, ofc.

Yes, and this is the part that I'm trying to allow, but without placing a GL parameter in the public interface as I wrap the JOGL binding dependency inside of my own.

Sven Gothel wrote

I hope this helps a bit.

~Sven

It does and I appreciate everyone's time, involvement, and help in this.

Thanks again,
-x