Posted by gouessej on Jul 26, 2016; 9:37pm
URL: https://forum.jogamp.org/Frame-briefly-opening-and-closing-during-Java3D-init-tp4036912p4036984.html

At first, it doesn't rely on the same parts of the Swing/AWT API and a lot less. As JogAmp's Ardor3D Continuation's canvases directly extend JOGL canvases, if something gets broken in AWT, it might break JOGL canvases whereas it's totally different in Java3D which uses a plain AWT canvas, Canvas3D directly extends java.awt.Canvas. The source code of Java3D canvases is harder to maintain because it was designed to support Direct3D and OpenGL, it manipulates AWT graphics configurations, devices, environments, events, ... JogAmp's Ardor3D Continuation uses Swing and AWT as few as possible whereas Java3D does exactly the opposite, it's strongly tied to AWT.

Secondly, it provides a canvas based on NEWT but using a bridge with AWT, JoglNewtAwtCanvas based on JOGL NewtCanvasAWT. It's possible to use NEWT as much as possible but still put the canvas into a Swing/AWT GUI. Then, the source code depending on NEWT isn't affected by AWT bugs and limitations and can be reused in a pure NEWT canvas, i.e JoglNewtWindow.

Thirdly, JogAmp's Ardor3D Continuation wraps some nice AWT-free utilities to load images, it's designed to work without AWT. Actually, you can use a compact profile without AWT to build JogAmp's Ardor3D Continuation except ardor3d-jogl-awt and ardor3d-awt of course.

However, Phil will provide a better way of using Java3D based on NEWT to make it work under Android but the AWT side will remain unchanged and weak.