Re: [gl4java-usergroup] nio buffers

[Kenneth B. R. <kbr...@al...>]

> GL4Java supports nio buffers with 1.4, but I'm unsure where exaclty they 
> increase performance. My guess that they speed up when you write to a 
> VertexBuffer, but not when you have static geometry data (i.e. 
> vertex/color/tex buffers drawn with glDrawElements in a Display List)

First and foremost, direct buffers fix a longstanding problem in
how certain OpenGL routines are accessed. In particular, the
client-side routines like glVertexPointer require the passed
pointer to not move in memory; before JDK 1.4, the only way to
portably implement this was to copy the vertex data out of the
heap. This copying imposes so much overhead that GL4Java actually
implements something incorrect, which is to hold onto the result
of a JNI GetPrimitiveArrayCritical call outside the
Get/ReleaseCritical block. In short, there was no efficient and
correct way to implement these routines before 1.4, and calling
glVertexPointer(..., float[] ptr) is not suitable for production
code as it opens up the possibility of crashes.

Direct buffers provide additional speedups. See the NVidia
VertexArrayRange demo in the GL4Java demos
(demos/NVidia/VertexArrayRange.java). This demo illustrates that
the same factor of two speedup available to C programs using the
NVidia vertex_array_range extension is now available to Java
programming language programs. The same *binary* runs on
GNU/Linux and Windows, and will soon run on Mac OS X.

Finally, the Grand Canyon demo illustrates that memory-mapping in
texture data is now possible, providing speed improvements and a
decrease in application footprint.