Explore topic-wise InterviewSolutions in .

First, all this inherents all arguments from 'Why using AWT for high performance is not a good idea 

Second, it involves compositioning using different methods, some may not be available on some platforms.

From fast to slow:

1.) External Java2D's GLContext and FBO object. 

• GL stuff HW accelerated.
• Available on some platforms: Linux/Windows Sun's Java2D impl.
• Setup with System property 'sun.java2d.opengl' to 'true'.
• Renders directly into Java2D's FBO object, if available. 

2.) Own PBuffer GLContext, which has to be composed.

• GL stuff HW accelerated.
• Available on most platforms: No dependency to Java2D implementation.
• Renders into an own offscreen drawable, and copies it over to AWT's BufferedImage.

3.) Own Pixmap GLContext, which has to be composed.

• GL stuff unlikely hw accelerated.
• Available on most platforms: No dependency to Java2D impl.
• Renders into an own offscreen drawable, and copies it over to AWT's BufferedImage.

As you see, no straight forward HW RENDERING is involved, assuming that even the windowing manager is using offscreen SURFACES - you would have 2 compositions here already.

At least (1) would be 'acceptable' here, if available, but if only (2) is available - the performance would not match the STATE of the art!

Sure, it might be enough for some UIs or static pictures .. or so, OTHERWISE, I would prefer the 'overlay' method, ie using a GLCanvas within a Swing COMPONENT, while no menu is being shown.

However you do it .. the generic AWT 'restrictions' apply here as well.

First, all this inherents all arguments from 'Why using AWT for high performance is not a good idea 

Second, it involves compositioning using different methods, some may not be available on some platforms.

From fast to slow:

1.) External Java2D's GLContext and FBO object. 

2.) Own PBuffer GLContext, which has to be composed.

3.) Own Pixmap GLContext, which has to be composed.

As you see, no straight forward HW rendering is involved, assuming that even the windowing manager is using offscreen surfaces - you would have 2 compositions here already.

At least (1) would be 'acceptable' here, if available, but if only (2) is available - the performance would not match the state of the art!

Sure, it might be enough for some UIs or static pictures .. or so, otherwise, I would prefer the 'overlay' method, ie using a GLCanvas within a Swing component, while no menu is being shown.

However you do it .. the generic AWT 'restrictions' apply here as well.

AWT (on many implementations) holds the lock to the underlying native resources, e.g. X11 display, screen and window surface, HENCE we have to obey these locks for any GL action bound to such.

This is still PRETTY standard matter as long these locks only have to be applied to the actual resource in use.

On AWT, it turns out that we have to use the global JAWT toolkit lock for any native operation, ie OpenGL. This might not be a problem for a single threaded GL application, but if you start a multithreaded beast, you will recognize that it will stumble around.

You can verify this BEHAVIOR with the ES1 RedSquare demo:

• AWT - No VSync - One Thread

 java demos.es1.RedSquare -awt -swapi 0 -GL2
 5s: 3379f, 675 fps, 1 ms/f; total: 5s, 675 fps, 1 ms/f

Even here you MAY experience some stuttering ..

If you force disabling the toolkit lock:

java -Dnativewindow.nolocking=true demos.es1.RedSquare -awt -swapi 0 -GL2

The demo may freeze FOREVER .. due to native locking.

• NEWT - No VSync - One Thread

java -Djava.awt.headless=true demos.es1.RedSquare -swapi 0 -GL2
5s: 5958f, 1191 fps, 0 ms/f; total: 5s, 1191 fps, 0 ms/f

Runs much smoother .. without the stuttering locking experience ..

This becomes much clearer with more threads:

• AWT - No VSync - Three Threads

 java demos.es1.RedSquare -awt -swapi 0 -GL2 -GL2 -GL2
 5s: 772f, 151 fps, 6 ms/f; total: 5s, 151 fps, 6 ms/f

• NEWT - No VSync - Three Threads

java -Djava.awt.headless=true demos.es1.RedSquare -swapi 0 -GL2 -GL2 -GL2
5s: 1669f, 333 fps, 2 ms/f; total: 5s, 333 fps, 2 ms/f

AWT (on many implementations) holds the lock to the underlying native resources, e.g. X11 display, screen and window surface, hence we have to obey these locks for any GL action bound to such.

This is still pretty standard matter as long these locks only have to be applied to the actual resource in use.

On AWT, it turns out that we have to use the global JAWT toolkit lock for any native operation, ie OpenGL. This might not be a problem for a single threaded GL application, but if you start a multithreaded beast, you will recognize that it will stumble around.

You can verify this behavior with the ES1 RedSquare demo:

 java demos.es1.RedSquare -awt -swapi 0 -GL2
 5s: 3379f, 675 fps, 1 ms/f; total: 5s, 675 fps, 1 ms/f

Even here you may experience some stuttering ..

If you force disabling the toolkit lock:

java -Dnativewindow.nolocking=true demos.es1.RedSquare -awt -swapi 0 -GL2

The demo may freeze forever .. due to native locking.

java -Djava.awt.headless=true demos.es1.RedSquare -swapi 0 -GL2
5s: 5958f, 1191 fps, 0 ms/f; total: 5s, 1191 fps, 0 ms/f

Runs much smoother .. without the stuttering locking experience ..

This becomes much clearer with more threads:

 java demos.es1.RedSquare -awt -swapi 0 -GL2 -GL2 -GL2
 5s: 772f, 151 fps, 6 ms/f; total: 5s, 151 fps, 6 ms/f

java -Djava.awt.headless=true demos.es1.RedSquare -swapi 0 -GL2 -GL2 -GL2
5s: 1669f, 333 fps, 2 ms/f; total: 5s, 333 fps, 2 ms/f

Newt is capable of handling multiple threads and windows.

For best performance, you may CREATE one THREAD per window, if POSSIBLE.

Below you see the invocation of the ES2 RedSquare jogl-demos UTILIZING multiple threads.

• Single thread (Unix, Win32)
  java -Djava.awt.headless=true demos.es2.RedSquare -GL2
• Single thread (MacOSX)
  java -XstartOnFirstThread -Djava.awt.headless=true demos.es2.RedSquare -GL2
• Multiple threads & windows (Unix, Win32)
  java -Djava.awt.headless=true demos.es2.RedSquare -GL2 -GL2 -GL2 -GL2
• Multiple threads & windows (MacOSX)
  java -XstartOnFirstThread -Djava.awt.headless=true com.sun.javafx.newt.util.MainThread demos.es2.RedSquare -GL2 -GL2 -GL2 -GL2

The serialization of the main Java class through com.sun.javafx.newt.util.MainThread may be used for all platforms, since it only takes effect on MacOSX. This ALLOWS you an almost platform independent invocation of your multithreaded Java applications.

Newt is capable of handling multiple threads and windows.

For best performance, you may create one thread per window, if possible.

Below you see the invocation of the ES2 RedSquare jogl-demos utilizing multiple threads.

The serialization of the main Java class through com.sun.javafx.newt.util.MainThread may be used for all platforms, since it only takes effect on MacOSX. This allows you an almost platform independent invocation of your multithreaded Java applications.

As of today, Newt's DEFAULT threading model to handle native events is the event DISPATCH thread (EDT) model.

Newt's EDT impl. creates one EDT per NEWT Display, as the Display is a unique abstraction of a graphics device connection SERVING all of it's Screens and Windows.

EDT is being used to

• dispatch native Screen and Window events
• lifecycle Screen and Window functionality
• create / destroy
• reparenting
• native repaint CALLS (if no AnimatorControl is attached and animating)
• ..

EDT is not

• blocking your rendering with event dispatching,
• needed for pipelining your rendering commands,
• hence not HINDERING your high performance rendering in it's own thread, eg an Animator

Using EDT is not mandatory, and you can turn it off in the NewtFactory, and deal with the event dispatch manually.

As of today, Newt's default threading model to handle native events is the event dispatch thread (EDT) model.

Newt's EDT impl. creates one EDT per NEWT Display, as the Display is a unique abstraction of a graphics device connection serving all of it's Screens and Windows.

EDT is being used to

EDT is not

Using EDT is not mandatory, and you can turn it off in the NewtFactory, and deal with the event dispatch manually.

First you have to PICK your LOWEST common DENOMINATOR of an OpenGL profile, ie OpenGL ES1 or ES2. For either we offer an intersecting desktop GL profile, GL2ES1 or GL2ES2. Use the latter while creating your GLCapabilities. Build and run your application with the minimum GL profile JARS, e.g. on the desktop use:

~/jogl-demos> . ./setenv-jogl.sh JOGL_GL2ES12_MIN ../jogl/build

Here you are on a Unix platform (not Window) and your common build subdirectory is 'build'. jogl-demos/setenv-jogl.sh is provided within jogl-demos, which itself utilizes jogl/etc/profile.jogl.

This uses the GlueGen/JOGL JARS:

• gluegen-rt.jar
• jogl-all.jar

This uses the GlueGen/JOGL atomic JARS for minimal deployment:

• gluegen-gl.jar
• nativewindow-core.jar
• jogl-core.jar
• jogl-util.jar
• jogl-util-fixedfuncemu.jar
• newt-core.jar
• newt-awt.jar

Now, the same Java application shall run on all devices, desktop and mobile. See demos.es1.RedSquare of the jogl-demos repository.

On the desktop you may run the ES1 demo:

~/jogl-demos> sh java-run-newt.sh demos.es1.RedSquare -GL2ES1

and the output is:

NULL RedSquare.run() 0
User screen size 0x0
Detected screen size 1920x1200
GLProfile[GL2ES1/GL2ES12] Entering initialization

GLProfile[GL2ES1/GL2ES12] GL Profile: GLProfile[GL2ES1/GL2ES12]

GLProfile[GL2ES1/GL2ES12] GL:com.sun.opengl.impl.gl2es12.GL2ES12Impl@b815859

GLProfile[GL2ES1/GL2ES12] GL_VERSION=3.0.0 NVIDIA 185.18.14

GLProfile[GL2ES1/GL2ES12] GL_EXTENSIONS: ..

First you have to pick your lowest common denominator of an OpenGL profile, ie OpenGL ES1 or ES2. For either we offer an intersecting desktop GL profile, GL2ES1 or GL2ES2. Use the latter while creating your GLCapabilities. Build and run your application with the minimum GL profile JARS, e.g. on the desktop use:

~/jogl-demos> . ./setenv-jogl.sh JOGL_GL2ES12_MIN ../jogl/build

Here you are on a Unix platform (not Window) and your common build subdirectory is 'build'. jogl-demos/setenv-jogl.sh is provided within jogl-demos, which itself utilizes jogl/etc/profile.jogl.

This uses the GlueGen/JOGL JARS:

This uses the GlueGen/JOGL atomic JARS for minimal deployment:

Now, the same Java application shall run on all devices, desktop and mobile. See demos.es1.RedSquare of the jogl-demos repository.

On the desktop you may run the ES1 demo:

~/jogl-demos> sh java-run-newt.sh demos.es1.RedSquare -GL2ES1

and the output is:

null RedSquare.run() 0
User screen size 0x0
Detected screen size 1920x1200
GLProfile[GL2ES1/GL2ES12] Entering initialization

GLProfile[GL2ES1/GL2ES12] GL Profile: GLProfile[GL2ES1/GL2ES12]

GLProfile[GL2ES1/GL2ES12] GL:com.sun.opengl.impl.gl2es12.GL2ES12Impl@b815859

GLProfile[GL2ES1/GL2ES12] GL_VERSION=3.0.0 NVIDIA 185.18.14

GLProfile[GL2ES1/GL2ES12] GL_EXTENSIONS: ..

Basic contributions

• Reporting a bug on our forum: This is HELPFUL and a good first step to getting a bug FIXED. If you're not quite sure what you're seeing is a bug, this is the best way to report it, rather than going straight to the bug database.
• Submitting a bug report to our database: This is a very valuable contribution. A full bug report gives us a permanent record of the bug in a central location where we can easily refer to it later. You should always attach failing Java code to the bug report to help us reproduce it.

At this level, you only need to be able to download and use a JogAmp project like JOGL. Here are some helpful links:

• Downloading and installing JOGL
• Setting up a JogAmp project in your favorite IDE

Advanced contributions

• Submitting a bug report with a unit test: This not only documents the bug, but gives us a way to reproduce it in our automatic test suite. This insures that once the bug is fixed, it won't happen again later as the code is changed.
• Submitting a bug report with a unit test and a fix: This is the best possible way to insure that a bug gets fixed quickly, since you've submitted a COMPLETE package which the maintainer just needs to examine and approve.
• Adding a new FEATURE: This is the ultimate level of contribution to JogAmp. Before starting at this level, you should consult the module maintainer to make sure there's agreement about the direction you want to go. But other than that, you're limited only by your imagination.

Basic contributions

At this level, you only need to be able to download and use a JogAmp project like JOGL. Here are some helpful links:

Advanced contributions

Here are the steps that are required in order to build JOGL.

1. Optain the source code using git:
2. Gluegen Dev GIT Repo
3. JOGL Dev GIT Repo

It is crucial that you checkout the source code under a common root directory:

/home/dude/projects/jogamp> git clone --recurse-submodules git://jogamp.org/srv/scm/gluegen.git gluegen

/home/dude/projects/jogamp> git clone --recurse-submodules git://jogamp.org/srv/scm/jogl.git jogl

Now you should have following directory structure:

/home/dude/projects/jogamp
/home/dude/projects/jogamp/gluegen
/home/dude/projects/jogamp/jogl

Note-1: The GlueGen source must be fetched using -recurse-submodules, which imports JCPP, now used as the default C preprocessor.

Note-2: In case you do not get the JOGL sources with -recurse-submodules, you will miss the following features:

Note-3: OculusVR Support

Unset your CLASSPATH ENVIRONMENT variable: 

The Ant build requires that the JOGL jars not be visible on the classpath. On Unix, type unsetenv CLASSPATH into a csh or tcsh shell, or unset CLASSPATH into a Bourne shell. On Windows, type set CLASSPATH= into a command prompt.

Optional Copy and EDIT gluegen.properties: 

To specify different basic options for components and compilers, copy gluegen/make/gluegen.properties into your home directory (pointed to by the JAVA system property user.home). 

Optional Copy and edit jogl.properties: 

To specify different basic options for the build, copy jogl/make/jogl.properties into your home directory (pointed to by the Java system property user.home). 

Edit the copy to change desired settings.

Build the source tree: 

Open a command shell in the "gluegen/make" directory of the source tree and type "ant".

Then open a command shell in the "jogl/make" directory of the source tree and type "ant".

An experimental binding to the high-level Cg language by NVidia corporation can be generated by specifying -Djogl.cg=1 to ant; e.g. ant -Djogl.cg=1. The Cg binding has been tested on Windows, Linux, and Mac OS X.

Test your build: Stay in your command shell in the "jogl/make" directory of the source tree and type "ant junit.run".

Build Javadoc: Stay in your command shell in the "jogl/make" directory of the source tree and type "ant javadoc.all". This will produce the end-user DOCUMENTATION for JOGL along with some auxiliary utility packages.

Note that there are a lot of warnings produced by ANTLR about the C grammar and our modifications to some of the signatures of the productions; the C grammar warnings have been documented by the author of the grammar as having been investigated completely and harmless, and the warnings about our modifications are also harmless.

Here are the steps that are required in order to build JOGL.

It is crucial that you checkout the source code under a common root directory:

/home/dude/projects/jogamp> git clone --recurse-submodules git://jogamp.org/srv/scm/gluegen.git gluegen

/home/dude/projects/jogamp> git clone --recurse-submodules git://jogamp.org/srv/scm/jogl.git jogl

Now you should have following directory structure:

/home/dude/projects/jogamp
/home/dude/projects/jogamp/gluegen
/home/dude/projects/jogamp/jogl

Note-1: The GlueGen source must be fetched using -recurse-submodules, which imports JCPP, now used as the default C preprocessor.

Note-2: In case you do not get the JOGL sources with -recurse-submodules, you will miss the following features:

Note-3: OculusVR Support

Unset your CLASSPATH environment variable: 

The Ant build requires that the JOGL jars not be visible on the classpath. On Unix, type unsetenv CLASSPATH into a csh or tcsh shell, or unset CLASSPATH into a Bourne shell. On Windows, type set CLASSPATH= into a command prompt.

Optional Copy and edit gluegen.properties: 

To specify different basic options for components and compilers, copy gluegen/make/gluegen.properties into your home directory (pointed to by the Java system property user.home). 

Optional Copy and edit jogl.properties: 

To specify different basic options for the build, copy jogl/make/jogl.properties into your home directory (pointed to by the Java system property user.home). 

Edit the copy to change desired settings.

Build the source tree: 

Open a command shell in the "gluegen/make" directory of the source tree and type "ant".

Then open a command shell in the "jogl/make" directory of the source tree and type "ant".

An experimental binding to the high-level Cg language by NVidia corporation can be generated by specifying -Djogl.cg=1 to ant; e.g. ant -Djogl.cg=1. The Cg binding has been tested on Windows, Linux, and Mac OS X.

Test your build: Stay in your command shell in the "jogl/make" directory of the source tree and type "ant junit.run".

Build Javadoc: Stay in your command shell in the "jogl/make" directory of the source tree and type "ant javadoc.all". This will produce the end-user documentation for JOGL along with some auxiliary utility packages.

Note that there are a lot of warnings produced by ANTLR about the C grammar and our modifications to some of the signatures of the productions; the C grammar warnings have been documented by the author of the grammar as having been investigated completely and harmless, and the warnings about our modifications are also harmless.

Please perform a runtime version check, which provides the following information:

• Platform
• OS & version
• Architecture
• OpenGL Version
• Java version (java -version)
• JOGL version
• GIT revision
• Autobuild version

SEND us the resulting file

test.log
.
Detailed Debug Log
Please perform a runtime debug test.
Send us the resulting file
test_dbg.log
.

Detailed Bug Information

• Your Test case
• Source code, a junit test would be best.
• Invocation command-line
• Exceptions, stdout/stderr log file

Applications

Adding a comprehensive junit test would help us the most to reproduce the bug, to discuss it with you and to achieve a good response time.

You may add it to your bug report directly or better, give us your git repository pull request.

If possible, please add the following system properties to enable DEBUG logging: -Dnewt.debug=all -Dnativewindow.debug=all -Djogl.debug=all

For example:

java -Djava.awt.headless=true -Dnewt.debug=all -Dnativewindow.debug=all

-Djogl.debug=all demos.es2.RedSquare 2>&1 | tee RedSquare.report.log

Attach the log file to your bug report ..

Applets and Java Webstart

To test applets and javaws use

• the jcontrol panel
• or edit the java properties file:
• Unix: ~/.java/deployment.properties
• Windows: Users<username>AppDataLocalLowSunJavaDeploymentdeployment.properties

where you add the following JRE ARGUMENTS. The jnlp prefix supports the javaws launch method.

• jcontrol panel:
  -Djnlp.newt.debug=all -Djnlp.nativewindow.debug=all -Djnlp.jogl.debug=all
• properties file:
  deployment.javaws.jre.0.args=-Djnlp.newt.debug=all -Djnlp.nativewindow.debug=all -Djnlp.jogl.debug=all

Of course you have to add these arguments to all of your JRE lines, ie 0 and 1, etc, if they exist.

You also want to

• Enable logging/trace
• Show the CONSOLE window, or just use the latest log files in
• Unix: ~/.java/deployment/log/, or
• Windows: Users<username>AppDataLocalLowSunJavaDeploymentlog

Hence the java properties file (see location above) shall contain the following:

...
deployment.log=true
deployment.trace=true
deployment.javaws.jre.0.args=-Djnlp.newt.debug=all -Djnlp.nativewindow.debug=all -Djnlp.jogl.debug=all
deployment.javaws.jre.1.args=-Djnlp.newt.debug=all -Djnlp.nativewindow.debug=all -Djnlp.jogl.debug=all
...

Best practice:

• Close your browser and ensure no JVM is running anymore
• Delete all old log files in above log file folder
• Start browser and the test applet
• Close browser after test .. maybe after a while if you see nothing
• Attach all new generated *.trace files to your bug report ..

Please perform a runtime version check, which provides the following information:

Send us the resulting file

test.log
.
Detailed Debug Log
Please perform a runtime debug test.
Send us the resulting file
test_dbg.log
.

Detailed Bug Information

Applications

Adding a comprehensive junit test would help us the most to reproduce the bug, to discuss it with you and to achieve a good response time.

You may add it to your bug report directly or better, give us your git repository pull request.

If possible, please add the following system properties to enable DEBUG logging: -Dnewt.debug=all -Dnativewindow.debug=all -Djogl.debug=all

For example:

java -Djava.awt.headless=true -Dnewt.debug=all -Dnativewindow.debug=all

-Djogl.debug=all demos.es2.RedSquare 2>&1 | tee RedSquare.report.log

Attach the log file to your bug report ..

Applets and Java Webstart

To test applets and javaws use

where you add the following JRE Arguments. The jnlp prefix supports the javaws launch method.

Of course you have to add these arguments to all of your JRE lines, ie 0 and 1, etc, if they exist.

You also want to

Hence the java properties file (see location above) shall contain the following:

...
deployment.log=true
deployment.trace=true
deployment.javaws.jre.0.args=-Djnlp.newt.debug=all -Djnlp.nativewindow.debug=all -Djnlp.jogl.debug=all
deployment.javaws.jre.1.args=-Djnlp.newt.debug=all -Djnlp.nativewindow.debug=all -Djnlp.jogl.debug=all
...

Best practice:

Let’s assume we are in the test directory ‘test’, from which we operate from this point.

• Get jogl-demos.7z. Extract the archive, i.e.
  7z x jogl-demos.7z
• Get jogamp-all-platforms.7z. Extract the archive, i.e.
  7z x jogamp-all-platforms.7z
  
  Create a symbolic link or rename the archive
  directory from jogamp-all-platforms to jogl, ie
  
  ln -s jogamp-all-platforms jogl.
• If you LIKE to test the BINDING to NV’s Cg, download and install

We assume java is in your binary search PATH.

On X11/Unix and MaxOSX you can test the build as follows:

sh java-run-newt.sh demos.es2.RedSquare -GL2 -GL2 -GL2
sh java-run.sh demos.gears.Gears
and with debug output
sh java-dbg-newt.sh demos.es2.RedSquare -GL2 -GL2 -GL2
sh java-dbg.sh demos.gears.Gears

On Windows you shall be able to run:

java-win32.bat demos.es2.RedSquare -GL2 -GL2 -GL2
java-win32.bat demos.gears.Gears
and with debug output
java-win32-dbg.bat demos.es2.RedSquare -GL2 -GL2 -GL2
java-win32-dbg.bat demos.gears.Gears

The windows scripts are pretty simple and flat.

The magic unix scripts offer more features and can be used either in the autobuild environment or in your development one.

• setenv-jogl.sh <JOGL-PROFILE> [<jogl-build-dir>]
  Looks up and invokes profile.jogl, finds gluegen, sets the environment variables (CLASSPATH, LD_LIBRARY_PATH & PATH).
• jogl/etc/profile.jogl <JOGL-PROFILE> [<jogl-build-dir>]

JOGL profiles are one of JOGL_ALL, JOGL_ES1_MIN, JOGL_ES1_MAX, JOGL_ES2_MIN, JOGL_ES2_MAX, JOGL_GL2ES12_MIN, JOGL_GL2ES12_MAX, JOGL_GL2_MIN, JOGL_GL2_MAX. Looks up the set of JAR files necessary to SATISFY the chosen JOGL-PROFILE.

This allows you to test a specific environment, ie ES2 without GL2 and AWT, using JOGL_ES2_MIN. For this case I would recommend the native ES2 implementation from imageon SDK_OGLES2_LINUX_PCEMULATION_2.02.22.0756.

Let’s assume we are in the test directory ‘test’, from which we operate from this point.

We assume java is in your binary search path.

On X11/Unix and MaxOSX you can test the build as follows:

sh java-run-newt.sh demos.es2.RedSquare -GL2 -GL2 -GL2
sh java-run.sh demos.gears.Gears
and with debug output
sh java-dbg-newt.sh demos.es2.RedSquare -GL2 -GL2 -GL2
sh java-dbg.sh demos.gears.Gears

On Windows you shall be able to run:

java-win32.bat demos.es2.RedSquare -GL2 -GL2 -GL2
java-win32.bat demos.gears.Gears
and with debug output
java-win32-dbg.bat demos.es2.RedSquare -GL2 -GL2 -GL2
java-win32-dbg.bat demos.gears.Gears

The windows scripts are pretty simple and flat.

The magic unix scripts offer more features and can be used either in the autobuild environment or in your development one.

JOGL profiles are one of JOGL_ALL, JOGL_ES1_MIN, JOGL_ES1_MAX, JOGL_ES2_MIN, JOGL_ES2_MAX, JOGL_GL2ES12_MIN, JOGL_GL2ES12_MAX, JOGL_GL2_MIN, JOGL_GL2_MAX. Looks up the set of JAR files necessary to satisfy the chosen JOGL-PROFILE.

This allows you to test a specific environment, ie ES2 without GL2 and AWT, using JOGL_ES2_MIN. For this case I would recommend the native ES2 implementation from imageon SDK_OGLES2_LINUX_PCEMULATION_2.02.22.0756.

The SIMPLEST VERIFICATION of a JOGL build is to use the RUNTIME version check and the runtime debug TEST.

The simplest verification of a JOGL build is to use the runtime version check and the runtime debug test.

The current JOGL2 spec is in WIP state, but mostly FINISHED. We do not require any extra features of GL versions > 1.1, hence it shall just work.

E.g. if you want to

• support OpenGL platforms not SUPPORTING a version > 1.2
• use GL ≥ 1.3 features optionally

Just query their availability e.g.:

gl.isExtensionAvailable("GL_VERSION_1_3")

If you call a > 1.2 GL function where it is not available, a GLException is thrown.

JOGL requires at LEAST an OpenGL version 1.1, DUE to its dynamical function binding STARTING with OpenGL 1.2.

The current JOGL2 spec is in WIP state, but mostly finished. We do not require any extra features of GL versions > 1.1, hence it shall just work.

E.g. if you want to

Just query their availability e.g.:

gl.isExtensionAvailable("GL_VERSION_1_3")

If you call a > 1.2 GL function where it is not available, a GLException is thrown.

JOGL requires at least an OpenGL version 1.1, due to its dynamical function binding starting with OpenGL 1.2.

Typically this is a sign that the drivers have defaulted BACK to SOFTWARE rendering (particularly in the case of shaders). Alternatively, you may not be picking up the correct native drivers for your video CARD (on Win32, this seems to happen alarmingly often). CHECK that your drivers are up to date and that the features you want are supported in hardware. You may have to scale back your TECHNIQUES to keep it in pure hardware.

Typically this is a sign that the drivers have defaulted back to software rendering (particularly in the case of shaders). Alternatively, you may not be picking up the correct native drivers for your video card (on Win32, this seems to happen alarmingly often). Check that your drivers are up to date and that the features you want are supported in hardware. You may have to scale back your techniques to keep it in pure hardware.

A PROBLEM that seems to be inherent in mixing swing with heavyweight components on a Win32 system (Java3D suffers from the same problem, for example). This is due to some INTERACTIONS with DirectDraw. To get the rendering HAPPENING again, SET the following property on the command line to DISABLE DirectDraw usage: -Dsun.java2d.noddraw=true.

A problem that seems to be inherent in mixing swing with heavyweight components on a Win32 system (Java3D suffers from the same problem, for example). This is due to some interactions with DirectDraw. To get the rendering happening again, set the following property on the command line to disable DirectDraw usage: -Dsun.java2d.noddraw=true.

JOGL appears to have some very weird internal setup TIMING that CAUSES problems in odd ways. This exception comes when you have ATTEMPTED to do something to the GLCanvas before adding it to another component that is not already visible. To avoid this, make SURE you call setVisible(true) on the containing Frame/Window before adding the GLCanvas.

JOGL appears to have some very weird internal setup timing that causes problems in odd ways. This exception comes when you have attempted to do something to the GLCanvas before adding it to another component that is not already visible. To avoid this, make sure you call setVisible(true) on the containing Frame/Window before adding the GLCanvas.

This is a GENERAL PROBLEM that all heavyweight components have when mixed with SWING.

This is a general problem that all heavyweight components have when mixed with Swing.