How does generated jogl C code implement gl calls using indirect buffers/java arrays?

Most jogl functions accept both direct and indirect data buffers, and in the indirect case simply passes the wrapped array to the native function 'dispatch_gl...........' (which accepts a java.lang.Object).

How does the C implementation of 'dispatch_gl...........' handle this?
 - Do you pin the java array in memory and then call the appropriate C gl function?
 - Or do you copy the indirect data into a direct buffer?
 - Do you have some kind of memory management strategy for this when it comes to potentially asynchronous read behavour?

I've read http://jogamp.org/jogl/doc/userguide/ but I don't see any details there.

Is the jogl C code generated by gluegen available somewhere to browse, or do we need to build jogl ourselves?

Hi

You need to build it, which isn't very difficult. It's documented and automated (with Ant).

Ok, I'll have a look at it later then.

What is surprising is that I achieve reasonable percentages of theoretical pcie transfer speeds by just using java arrays, so I don't see any gains by using direct buffers.

Den 2015-01-27 17:18, GiGurra [via jogamp] skrev:
> Ok, I'll have a look at it later then.
>
> I achieve reasonable percentages of theoretical pcie transfer speeds
> by just using java arrays, so I don't see any gains by using direct
> buffers (which is a little surprising).
>

Direct buffers are mandatory for stability because it will prevent the
garbage collector to move memory that is in use by the OpenGL library.
If you only try to use java arrays you will run into odd crashes when
the GC moves memory in use by the GL impl.

You should look at the native memory footprint. JOGL does its best but not passing direct NIO buffers is a very bad idea and I'm not sure that we will keep the methods that accept the arrays in the future.