Re: [gl4java-usergroup] nio buffers

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

> I would like to have an applet run in both 1.1 and 1.4 and that's the reason 
> I ask. When using display lists, the vertex data buffers are copied, and I 
> would presume that it doesn't matter what method you use (except the nasty 
> GL4Java implementation you descibe).

I recommend writing an application instead of an applet and
deploying it with Java Web Start (and ignoring 1.1.x
compatibility). There are no browser compatibility issues with
JWS, but I have seen plenty of compatibility problems with
applets, even between Netscape and IE.

> > 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.
> 
> But this only applies for dynamic geometry, right?

Not necessarily. You don't have to update the data in the vertex
arrays every frame.

> > Finally, the Grand Canyon demo illustrates that memory-mapping in
> > texture data is now possible, providing speed improvements and a
> > decrease in application footprint.
> 
> I'm not sure what you mean by memory-mapping textures, is it also something 
> with dynamic textures (like avi textures)?

What I meant is sending the texture data from disk directly to
OpenGL without needing to read it into an auxiliary data buffer.
This requires the texture to be in "raw" format (typically
uncompressed and with no file format.)