* Get [http://download.java.net/media/jogl/builds/nightly/ jogl-2.0-pre-20090702-linux-amd64.zip]. In case we have build a reference implementation (RI) the substring ‘pre-yyyymmdd-’ will be dropped. Replace the version 2.0 with the latest available and the OS/arch linux-amd64 with your test platform. Extract the archive, ie <pre>unzip jogl-2.0-pre-20090702-linux-amd64.zip</pre>. Create a symbolic link or rename the archive directory from ''jogl-2.0-pre-20090702-linux-amd64'' to ''jogl'', ie <pre>ln -s jogl-2.0-pre-20090702-linux-amd64 jogl</pre>.

* properties file: <pre>deployment.javaws.jre.0.args=-Djnlp.newt.debug\=all -Djnlp.nativewindow.debug\=all -Djnlp.jogl.debug\=all</pre> 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

* Enable logging/trace

−

* Show the console window, or just use th latest log-file in <pre>~/.java/deployment/log/</pre>

== Why you should learn direct from start the modern OpenGL (programmable and shader based) over the deprecated fixed function pipeline ==

+

+

I see everyday A LOT of beginers who start with the old deprecated OpenGL. This is wrong, this is so wrong. [https://github.com/elect86/ I, personally,] went through this and today I realize I did it wrong and I wished someone could have told me that at the time I start.

+

+

In order to say you why you should start right away learning modern OpenGL, I will use the words of [http://web.archive.org/web/20140207031129/http://www.arcsynthesis.org/gltut/About%20this%20Book.html Jason L. McKesson]:

+

+

"

+

Programmability. Virtually all of the aforementioned sources instruct beginners using something called “fixed functionality.” This represents configurations in older graphics processors that define how a particular rendering operation will proceed. It is generally considered easiest to teach neophyte graphics programmers using the fixed function pipeline.

+

+

This is considered true because it is easy to get something to happen with fixed functionality. It's simpler to make pictures that look like something real. The fixed function pipeline is like training wheels for a bicycle.

+

+

There are downsides to this approach. First, much of what is learned with this approach must be inevitably abandoned when the user encounters a graphics problem that must be solved with programmability. Programmability wipes out almost all of the fixed function pipeline, so the knowledge does not easily transfer.

+

+

A more insidious problem is that the fixed function pipeline can give the ''illusion'' of knowledge. A user can think they understand what they are doing, but they're really just copy-and-pasting code around. Programming thus becomes akin to magical rituals: you put certain bits of code before other bits, and everything seems to work.

+

+

This makes debugging nightmarish. Because the user never really understood what the code does, the user is unable to diagnose what a particular problem could possibly mean. And without that ability, debugging becomes a series of random guesses as to what the problem is.

+

+

By contrast, you cannot use a programmable system successfully without first understanding it. Confronting programmable graphics hardware means confronting issues that fixed function materials often gloss over. This may mean a slower start overall, but when you finally get to the end, you truly ''know'' how everything works.

+

+

Another problem is that, even if you truly understand the fixed function pipeline, it limits how you think about solving problems. Because of its inflexibility, it focuses your mind along certain problem solving possibilities and away from others. It encourages you to think of textures as pictures; vertex data as texture coordinates, colors, or positions; and the like. By its very nature, it limits creativity and problem solving.

+

+

Lastly, even on mobile systems, fixed functionality is generally not available in the graphics hardware. Programmability is the order of the day for most graphics hardware, and this will only become more true in the future.

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.

Bugreports & Testing

For all bug reports, please add the following information to
your bug report:

Common Runtime Problems

X11: OpenGL library is not picked up correctly, no OpenGL available

In case you are running a DRI machine, eg ATI's proprietary driver or
an open source one, you may need to ensure that the environment variable LIBGL_DRIVERS_PATH
is set properly.

I ran into this while testing the 32bit builds on a 64bit machine
as a different user. Since LIBGL_DRIVERS_PATH is only setup for the desktop user
on Ubuntu, some /etc/X11/Xsession.d/ script, I couldn't get a GL context to work.

How to develop Cross-Device Applications

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.

What is Newt's Threading Model for native window events ?

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.

It's introduction was necessary to allow a peace of mind,
high performance and reactive solution of the dispatch event problem.
Some OS, especially MS-Windows, require one to create the native Window
and dispatch it's events from the same native thread.
As it was easy to handle these requirements from a simple test application,
as it is difficult to solve this from a framework operating with multiple temporary threads,
a web browser for example.

How to use Newt with multiple Windows & Threads

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.

On MacOSX, com.sun.javafx.newt.util.MainThread will occupy the main thread and
serializes all native window related tasks through it.
This mechanism is thread safe utilizes reentrant locking.

Why using AWT for high performance is not a good idea ?

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.

Why you should learn direct from start the modern OpenGL (programmable and shader based) over the deprecated fixed function pipeline

I see everyday A LOT of beginers who start with the old deprecated OpenGL. This is wrong, this is so wrong. I, personally, went through this and today I realize I did it wrong and I wished someone could have told me that at the time I start.

In order to say you why you should start right away learning modern OpenGL, I will use the words of Jason L. McKesson:

"
Programmability. Virtually all of the aforementioned sources instruct beginners using something called “fixed functionality.” This represents configurations in older graphics processors that define how a particular rendering operation will proceed. It is generally considered easiest to teach neophyte graphics programmers using the fixed function pipeline.

This is considered true because it is easy to get something to happen with fixed functionality. It's simpler to make pictures that look like something real. The fixed function pipeline is like training wheels for a bicycle.

There are downsides to this approach. First, much of what is learned with this approach must be inevitably abandoned when the user encounters a graphics problem that must be solved with programmability. Programmability wipes out almost all of the fixed function pipeline, so the knowledge does not easily transfer.

A more insidious problem is that the fixed function pipeline can give the illusion of knowledge. A user can think they understand what they are doing, but they're really just copy-and-pasting code around. Programming thus becomes akin to magical rituals: you put certain bits of code before other bits, and everything seems to work.

This makes debugging nightmarish. Because the user never really understood what the code does, the user is unable to diagnose what a particular problem could possibly mean. And without that ability, debugging becomes a series of random guesses as to what the problem is.

By contrast, you cannot use a programmable system successfully without first understanding it. Confronting programmable graphics hardware means confronting issues that fixed function materials often gloss over. This may mean a slower start overall, but when you finally get to the end, you truly know how everything works.

Another problem is that, even if you truly understand the fixed function pipeline, it limits how you think about solving problems. Because of its inflexibility, it focuses your mind along certain problem solving possibilities and away from others. It encourages you to think of textures as pictures; vertex data as texture coordinates, colors, or positions; and the like. By its very nature, it limits creativity and problem solving.

Lastly, even on mobile systems, fixed functionality is generally not available in the graphics hardware. Programmability is the order of the day for most graphics hardware, and this will only become more true in the future.
"