Posted by xghost on Jul 29, 2015; 5:37am
URL: https://forum.jogamp.org/Can-JOGL-be-used-without-requiring-GLAutoDrawable-instances-tp4034953p4034992.html

gouessej wrote

I'm not sure that using the assisted API forces you to expose anything that would be a concern for the encapsulation.

Maybe for clarification, but what parts do you consider part of the 'assisted API'? Just want to make we're on the same page and that I'm not misunderstanding something.

gouessej wrote

Sorry for the confusion. If you don't use the assisted API, you might have some problems anyway in some cases, for example when the OpenGL context must be created on a particular thread or when its creation is expected to fail several times on very poor drivers under Windows.

Are you thinking that I'm trying to create an OpenGL context 'manually'? I do intend to implement interfaces like GLEventListener (in a Renderer impl class), and this part is pretty easy to hide from clients.

gouessej wrote

Why not using the assisted API without exposing any GL instances directly?

Pending clarification on 'assisted API', it seems this would be preferable.

gouessej wrote

The desire of hiding JOGL sometimes leads to badly designed code.

But not hiding details that are/should-be internal to my library (e.g. JOGL) would cause undesired coupling. I'm trying to avoid both :)

gouessej wrote

Moreover, if your students need to code in OpenGL, they will have to use JOGL.

They're not expected to work directly with OpenGL, only with a class to manage the scene and, at the lowest level, the renderer, but not directly with OpenGL API. (There's a separate course on graphics using OpenGL for that.) They're however, expected to interact with shaders in an abstracted way, which is where the classes I'm working on come in.

gouessej wrote

Look at how I "hide" JOGL most of the time in several major scenegraph API including JogAmp's Ardor3D Continuation and JMonkeyEngine.

I took a look at the JOGL renderers in both JME3 and Ardor3D frameworks.

The JoglRenderer classes in both frameworks are doing exactly what I'm doing inside of my shader classes when I want to let users apply operations (e.g. set the value for a uniform in a shader) without exposing the JOGL and/or GL instances to them, i.e. using the GLContext to get the GL instance.


This example, starting in line 128, does that when letting clients set the background color:

// in com.ardor3d.renderer.jogl.JoglRenderer
@Override
public void setBackgroundColor(final ReadOnlyColorRGBA c) {
    final GL gl = GLContext.getCurrentGL();

    _backgroundColor.set(c);
    gl.glClearColor(_backgroundColor.getRed(), _backgroundColor.getGreen(), _backgroundColor.getBlue(), _backgroundColor.getAlpha());
}

Something similar happens in JME3's JoglRenderer, with its initialize() method is invoked (starting line 148):

// in com.jme3.renderer.jogl.JoglRenderer
public void initialize() {
    GL gl = GLContext.getCurrentGL();
    // ... some comments ....
    if (gl.isExtensionAvailable("GL_VERSION_2_0")) {
    // ....

For comparison, a relevant portion in one of my shader classes representing a Uniform input for a shader. Notice that the GL instance is not passed in, it's acquired just like in the previous snippets from Ardor3D/JME3:

@Override
public void set(Float value) {
    // ...
    GL4 gl = GLContext.getCurrentGL().getGL4();
    gl.glUniform1f(location, value);
}

However, if I understand you correctly, using JOGL this way is what you're recommending against. Is this correct?

I'm thinking that I may've misunderstood what you mean by 'assisted API' or something else, perhaps.

Thanks again,
-x