Posted by
Sven Gothel on
Jan 17, 2020; 7:13pm
URL: https://forum.jogamp.org/Mixing-C-and-Java-opengl-calls-with-JOGL-tp4040269p4040271.html
On 1/17/20 7:24 PM, christopherplawrence [via jogamp] wrote:
> 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
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