JOGL and nio

OpenGL Development JOGL Development
#1

Hey!

I am looking into jogl and lwjgl at the moment, and i wonder why
they both need the use of nio buffers. I know opengl from c++ programming;
if I wanted to pass data to a function, I passed the pointer - very easy.
Now in java, I have to create a nio buffer… very unused to me, feels really
strange.
My question is: Why exactly are these buffers needed ? I suppose because
of different memory layouts of java arrays and c arrays, is that right ? If I put
an int into an IntBuffer, the format of the integer gets converted from java to c ?
I had a look into C# and the Tao framework, and it seems they don´t need it.
Tao allows to pass C# arrays directly to GL, which seems to be much more convenient.

Maybe I am to picky about these things, but I don´t really like these unstructured
primitive buffers… they feel a bit like a hack, but maybe I am wrong - tell me, please :slight_smile:

thanks,
Frederick

#2

Read this thread at the LWJGL forums.

#3

Hi Frederick

JOGL used to have arrays arguments to OpenGL calls, but the NIO buffer stuff is faster, since a direct buffer results in a pointer on the native side.

cylab

#4

The slides from JavaOne 2002 on the JOGL home page describe the reason for using Buffers vs. arrays in certain situations. The “speed” of passing the data down to C has nothing to do with it – no data copy occurs in either case. The issue is the semantics of the C function you’re calling and whether it retains a persistent pointer to the data being passed down. If it does (like glVertexPointer, glNormalPointer, etc.) then you have to use a “direct” NIO Buffer to pass down the data, since then the Buffer’s contents aren’t managed by the Java garbage collector and won’t move out from underneath the C function while it’s operating on the data. JOGL still has an array overloading for every C function where the semantics allow it.

#5

Sorry for spreading rubbish then :wink:

#6

Hey,

thank you very much ! I am getting excellent informed at this forum. Thumbs up.
Thanks to all of you, thanks for the slide Ken.

To say in in my own words: The problem with standard java objects is, that they may
change their position in memory, because of garbage collection. The garbage collector
is running in parallel to the program, and also running in parallel to the invoked c code.
During the execution of the C Program, the GC may move the java object to another place in memory -
the pointer gets invalid.
This may be solved by:

  1. pinning down the java object - let the GC ignore it
    2)Disable the GC during native invocation

1 is difficult to do,
2 has inacceptable restrictions:
Example: a GL_BindTexture may invoke
a copying process from RAM to the GPU, which is running
in parallel to the C Program, which may return to Java, before
the copying is finished, and the pointer is in danger again.

So NIO is introduced.
At the heart a NIO buffer is buffer in unmanaged space, and is not affected by the
gc. This is the way NIO solves the problem.

Did I get it right?

I am not a pro, so maybe I am wrong, but I really would have preferred to introduce them
“unmanaged” memory, which must be newed and deleted by hand, like in c - for java.
Perhabs an “unmanaged_new” operator or something like this. This would allow for
structured data - like objects etc. But its not there :’(

Thanks for your awesome help,
Frederick