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