Mixing C and Java opengl calls with JOGL

Apologies if this has already been answered; I've spent a while searching and have come up empty.

I have an Android application using GLES 3.0, invoked both through the Java and C APIs. I am trying to transition this to JOGL so it can be run on desktop as well.  I'm assuming that mixed invocation should be possible.  I would like to have JOGL manage the context.

How should I configure the build of my C library so that it's linked to the same definitions for the GLES API as what JOGL will be using at runtime?

I am using "jogamp/make/stub_includes" and "gluegen/make/stub_includes" for the include path, but am at a dead end for linking.

My environment is Windows/VS.  I can switch to any other desktop environment to get an initial prototype going, but will need windows (compiler agnostic) for eventual production.

After spending some more time thinking about it, I believe that the linking has to occur dynamically at runtime.  My library will need to provide the gl* function definitions.  The implementation will delegate calls to function pointers.  These function pointers will be obtained, at runtime, from the GL library that was loaded by JOGL.

The basic idea is:
- obtain the handle to the GL implementation loaded by JOGL
- initialize the C library's internal GL function pointers via dlsym/GetProcAddress
- the C library's internal gl* function definitions proxy to the dynamically loaded function pointers

Guidance is still very much appreciated if anyone has experience with what I'm trying to do.

On 1/17/20 7:24 PM, christopherplawrence [via jogamp] wrote:
This is correct and already performed by JOAL, JOGL and JOCL via GlueGen.

Have a look into the type hierarchy of
'com.jogamp.gluegen.runtime.ProcAddressTable'

For example, you will find 'jogamp.opengl.es3.GLES3ProcAddressTable',
which covers GLES2 and GLES3.
Where 'jogamp.opengl.gl4.GL4bcProcAddressTable' covers the whole desktop GL
implementations.

You may use these already resolved function pointers in your native code.

+++

How do we get to the point where this table is filled?

We utilize the interface 'com.jogamp.common.os.DynamicLookupHelper',
i.e. its implementation 'DynamicLibraryBundle' (JNI lib + tool lob)
or 'NativeLibrary'.

For GL, the GLDynamicLookupHelper instance can be retrieved via
'jogamp.opengl.GLContextImpl.getGLDynamicLookupHelper()'

Since the table is already fully established and all
function pointers looked up, you surely want to use it.

You can retrieve the table via
'jogamp.opengl.GLContextImpl.getGLProcAddressTable()'.

You will see the magic of runtime type info being used,
as we operate on the field's name itself plus some
GL name aliasing on extensions.

How can you use this in a statically compile unit is the problem for you.
In ProcAddressTable you see the private 'toMap' method,
generating a Map<String, Long) from function name to function pointer.

Knowing that GlueGen already creates the Java JNI code, its native C
entry stubs and the whole function tables, one could also use it
to generate a native C GL wrapper library for all GL functions.
Here this wrapper would be utilize a pre-initialized map (C-code)
filled from the Java [GL4bc]ProcAddressTable to fetch its function
pointer at runtime.

A very similar technique is used in regular GL front-end libs, e.g Mesa.

This could become an interesting extension.

Hope it helps.

~Sven

Thank you for the detail, Sven.  Pulling the address pointers from the ProcAddressTable greatly simplified the work I had to do.

I've been able to confirm issuing commands against the C GL API from native in an initial experiment (modified the 'hello-triangle' example project to use JNI to invoke some commands from native).  I am working through hacking together a more extensive prototype now.  I will eventually be putting together a production-level wrapper.  I'm happy to share the code back in the future as either an example or an extension.

If this is a topic of interest to you, I will reach out in the future to further explore your thoughts on using GlueGen to  automate creation of the wrappers.