[External] : Re: JEP-412 & OpenGL

[Martin Pernollet]

*Report about more intensive use of foreign function API*

I have plugged mouse control and automated rotation to the PanamaGL prototype [0]. I have let a native frame opened for an hour and didn’t notice any crash. The only JVM crashes I encountered were when I got an exception in a callback due to me. As Jorn said, a complete stack print would be helpful to locate where the bug comes from. One can reproduce crashes without exception with the teapot example modified as follow :

 void onIdle() {
   throw new IllegalArgumentException("Teapot does not support coffee");
 }

My CPU is busy (60%) but this is normal : this prototype uses glutMainLoop(), which will let the GPU run and invoke CPU/JVM at each frame. At each frame, Jzy3D will invoke all OpenGL methods to render geometries in immediate mode (a.k.a fixed function pipeline). There are ways to do things more efficiently in Jzy3D with a single communication between GPU and CPU at program start, but I think it is better to stick on such non-efficient way of rendering for the purpose of challenging JEP-412.

I did not implement a couple of things for the prototype (text, automatic HiDPI detection, image overlays, screenshots, etc) because there are harder questions that I would like to discuss before.


*Integration in an AWT Canvas*

Embedding a GL renderer into an existing AWT application could be done by rendering the image offscreen, fetching it to convert as a BufferedImage and then add it in an AWT Canvas. This is however inefficient since the pixels will go from GPU to CPU and then back to GPU.

It would be more efficient to execute GL code in GPU in a viewport relating to the canvas where we intend to draw. Beside being more efficient, this would also comply with the need of OpenGL to be invoked by a single thread. The authors of JOGL did this by defining a GLEventListener[1] interface that must be registered on a GLCanvas. The GLCanvas will invoke the GLEventListener, and the implementation of GLEventListener.display must define what to draw, e.g. a teapot, a collection of polygons, etc.

I hence would like to hook where a Canvas gets rendered by AWT and execute GL code from there. I found this package [2] to be instructive for the native OpenGL side, SunGraphics2D lead me to PixelDrawPipe, then CompositeCRenderer where I get a bit lost for now as it relies on SunGraphics2D back. I would enjoy any suggestion clarifying who actually draws an AWT widget, and where is the link between Graphics2D and OpenGL.

Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :)

I know that Apple has shifted to Metal on MacOS, that JDK now has the ability to use it for rendering and that I would have to deal with OpenGL + Metal that should fit under the same interface (implementing an OpenGL interface with Metal would probably be the best way).

*More practical questions about JExtract*

I presume I should not have to build an OpenGL binding with JExtract for each OS/Version, because OpenGL is a specification and all computer vendors should provide .h that follow the same specs. So my understanding is that JExtract should in theory be ran for each OS/Version, but in practice can be ran once on my computer and will be OK for Windows and Linux for the OpenGL case.

Last, I wonder if exposing OpenGL through JExtract from an AWT Canvas would be compatible with using OpenGL to render usual AWT widgets with native OpenGL inside the JVM?

Thanks for reading!

Martin

[0] https://github.com/jzy3d/panama-gl
[1] https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html
[2] https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl