Ok i will check out the NIO api when i get the time. But i have to admit im not seeing the big picture for clueless newbes about using it IF we have to do specific JNI code. We could just ignore NIO a create our own JNI code that could be even more optimized for our game without the restrictions of having to suport NIO requirements.
Yup, your not getting it.
Let me take a step back l now that I *know* this is a clueless newbie discussion and explain. Lest start with Native Byte Buffers, just one of the NIO features:
In a typical Windows system running a Java application there are three very distinct and seperate hunks of memoy.
There is the device memory, an example of which being the memory on your video card that all geometry and textrues have to get to before you can render.
There is the C heap, which is the memory that the Java heap comes from as well as all memory you allocate in C from JNI.
Then there is the Java Heap, which is Java's memory. All data new'd in Java comes from the Java Heap.
In the worst case, using JNI, you would have to do the following to get geometry from Java to the video card:
For every Geomrtry Change:
(1) Allocate memory in the Java heap and build your geometry.
(2) Call thorugh JNI (at some cost) to a C side function.
(3) C side function calls back to Java to get the geometry. (Significant cost PLUS a full data copy from the Java heap to the C heap.
(4) C function then calls an openGL function to set that in the video memory (ANOTHER data copy operation ocurrs.)
Now OGL, thansk to Nvidia, now supprots a way to get a "window" into the video card's memory and write to that directly from C. Using this you could eliminate step 4 by pre-allocating that window and then passing THAT to Java to copy the data into in step 3. This however does nothing about the really expensive part., which is moving the data from the Java heap to the C heap.
NIO introduces Native Direct Byte Buffers. These are sturctures that look like Byte Buffers from the Java side but are really pointers directly into the machine's memory space.
Combining the vdieo card geoemtry "window" and a native byte buffer, the code looks like this
(1) Call throgh JNI to a C function that gets that video card memory window and wraps a Native Direct Byte Buffer around. It then returns the Natvie Direct Byte Buffer to the Java function that called the Native function, (Modest cost).
For every geometry change.
(1) Write the geoemtry DIRECTLY into video memory from Java using the NDBB.
<do whatevr else you want to set up render>
(2) Call a JNI function once per frame that requires no data and returns no data. All it does is kick the card to render whats already been set into it.
See? You avoid MANY data copies as well as pulling data from the Java heap to the C heap which is quite expensive in of itself.
It brings us to the question if having a direct binding to OpenGL and trying to patch the limitations of such aproach with packs like NIO is really a better option than creating a core native 3d engine independent of OpenGL and NIO and specialized to take advantage of Java OO features.
In short, yes it is.
Your going to have to talk to OGL anyway. And if you use the features of Java correctly its really not appreciably more expensive then calling OGL from C.
And the more code you can do in java, the more portable you are, the less buggy you are., the faster your project is done, and the happier you will be
NOTE: When i say independent i mean not having to be one-to-one mapping of structures and functions from OpenGL to Java.
It isnt a one to one mapping on the code level. There is a mapping on the API level because the OGL API is proven and there is a huge body of knowledge on how to use OGl effectively already in existance.
But the assumption that every JOGL API call just calls the matching C API call across JNI in a dumb fashion is patently false.