Interfaces/Java Native OpenGL
These are a few OpenGL demos to be run on various platforms to compare their performance with that of OpenGL demos in J 601 and 602. The goal is to give a chance to see the difference and decide whether the existing J performance is adequate or such acceleration is worth the effort.
Each archive contains a runnable application and sources. See readme.txt in each archive for further details.
Make sure Java and J are installed and paths are correct: path to J in run.bat and libj601.dylib (.so) in /usr/lib. Check for /usr/lib/libGL.so and symlink if necessary.
- {
JAWTOpenGL JAWTAtlantis JayOpenGL3 JayOpenGL4 
JAWTOpenGL JAWTAtlantis JayOpenGL3 JayOpenGL4 
JAWTOpenGL JAWTAtlantis JayOpenGL3 JayOpenGL4 
JAWTOpenGL:: basic idea how Java can show native hardware-accelerated OpenGL, using JAWT, a bridge between the Java canvas and a native device context, which is prepared for direct drawing with native OpenGL calls JAWTAtlantis:: famous OpenGL demo from SGI with complex models and behavior, using the same OpenGLCanvas Java bridge JayOpenGL3:: j601 version. A Java application calls J's OpenGL demo as is to do the drawing. Context creation from J side is disabled, and controlled from Java. J executes only pure OpenGL. When switching between scenes, defaults are reset. However, artifacts are visible (such as wrong light), there is Options/Reset to be called from the menu. JayOpenGL4:: j602 version, same as above.
Demo Notes
The demos are called native to distinguish the fact that it's the native library that does the on-screen painting, as opposed to J where an off-screen buffer is painted. This translates to physical hardware processing on systems which support harware acceleration, such as Mac and Windows. Note, Mesa may use software rendering, but in these demos it takes care of painting to the underlying GUI system without a roundtrip to J, though there should be OpenGL drivers and librarires for Linux provided by video card manufacturers.
The "Jay" demos have menus corresponding to the OpenGL demo. The Options menu has the Reset item to "reset" the OpenGL context (see above) in particular it is discarded and re-created.
Mouse click on the canvas with pause the timer. This is for capturing an angle or to run several applications and compare side-by-side performance letting run one at a time.
Observations
Different J demo scenes compare differently between these demos and the J system, based on characteristics of the scene.
Regular scenes, using simple to medium geometry complexity, benefit directly from hardware acceleration, running several times faster. This is especially visible on medium to large windows.
Models breakable into lists perform better, as shown in the second Jay demo. To be able to use lists effectively, the painting code should be broken into two parts: setup and paint.
Models with very complex geometry do not benefit (much) from acceleration.
JayOpenGL2 Mesa produces interestingly stripy surfaces -- Oleg Kobchenko <<DateTime(2006-05-05T19:51:53Z)>>
OpenGL hardware accelerated rendering is much more efficient than using bitmap, because the bulk of the work is done in the graphics card GPU:
- it is faster
- it does not use as much memory
- it does not use as much CPU
It was shown how OpenGL can be rendered to the hardware, as opposed to bitmap, with J cd calls for J Windows Front End.
Now the same can be done for Java front ends. The requirement is to create a very thin bridge, not like JOGL, esp. that we are not planning to call OpenGL from Java.
The idea is to use JAWT JNI support, and configure the OpenGL context to connect to the native "drawable" (the native OS peer canvas control) that underlies the Java Canvas.
Because OpenGL libraries and the native drawable are different on different platforms, this may require different JNI implementations. But java code could be the same.
Alternatives:: require now standardized Java OpenGL support jogl.
Windows
The approach was inspired by very economical skeleton implementation as described in
Embed OpenGL inside Java AWT Canvas
The example runnable code and sources can be downloaded from there. This work also contains many good references.
Darwin
I created an original implementation for OpenGL/Cocoa JNI, which has similar approach to the Windows example, but uses different native support. With help from Dmitry Markman from java-dev Apple mail list, and other sources, it is now better optimized.
The project was done and tested on OS X 10.4.6 with XCode 2.2 even with GCC 4.0. However, to my surprise, the binary application worked out-of-the-box on OS X 10.3.9 (Panther) in a X86 emulator.
The frame rates are very good. Even on emulator it runs smoothly at 20-30 fps. On a real machines it runs a few hundred fps in single window and a few dozen with several windows open.
Linux
Example of X11 JAWT is provided at
The AWT Native Interface from Sun Microsystems.