[External] : Re: JEP-412 & OpenGL
Jorn Vernee
jorn.vernee at oracle.com
Fri Nov 12 14:17:20 UTC 2021
Hi Martin,
Thanks for testing this!
The UnsatisfiedLinkError is not from code looking for a header file,
it's from looking for a library/.dll file named GL.dll. On Windows
though, freeglut needs the opengl libraries that come bundled with
Windows (found in C:\Windows\System32), named opengl32 and glu32. The
script should already add -l flags for those.
---
WRT the jextract error you see.
I have not tried to run the sample with freeglut installed through MingW
yet. I instead used the freeglut package for MSVC here:
https://www.transmissionzero.co.uk/software/freeglut-devel/ extracted
that in some folder, and the pointed freeglutPath at that folder.
Note that jextract is using clang underneath to do the parsing. I know
clang works pretty well with MSVC/Windows SDK header files, but I'm
guessing it can not understand the MingW headers, looking at your error.
I think it's having problems with __MINGW_NOTHROW and
__MINGW_ATTRIB_NORETURN, which look like compiler builtins.
I'd suggest trying the freeglut package I linked to instead, together
with the Windows SDK headers (which clang should find automatically),
and taking MingW headers out of the equation for now. We should probably
create a README for that sample to include instructions on how to get
freeglut.
Note that on top of that, you will also have to change Teapot.java to
account for a change in parameter names resulting in slightly different
code being generated by jextract [1].
HTH,
Jorn
[1] :
diff --git a/opengl/Teapot.java b/opengl/Teapot.java
index 22d1f44..d5eb786 100644
--- a/opengl/Teapot.java
+++ b/opengl/Teapot.java
@@ -79,8 +79,8 @@ public class Teapot {
glutInitWindowSize(500, 500);
glutCreateWindow(allocator.allocateUtf8String("Hello Panama!"));
var teapot = new Teapot(allocator);
- var displayStub =
glutDisplayFunc$func.allocate(teapot::display, scope);
- var idleStub = glutIdleFunc$func.allocate(teapot::onIdle,
scope);
+ var displayStub =
glutDisplayFunc$callback.allocate(teapot::display, scope);
+ var idleStub =
glutIdleFunc$callback.allocate(teapot::onIdle, scope);
glutDisplayFunc(displayStub);
glutIdleFunc(idleStub);
glutMainLoop();
On 12/11/2021 13:01, Martin Pernollet wrote:
> Thanks for your answer. I tried running on Windows an OpenGL binding generated on MacOS, and it fails on much simpler things. The glut_h file from Mac starts with lib names and path that are not relevant for Windows :
>
> public class glut_h extends glut_h_3 {
> static {
> System.loadLibrary("GL");
> System.load("/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT");
> }
>
> while on Windows the path is "C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include" when using Freeglut built with MinGW.
>
> Fixing manually in the generated glut_h won't help : Exception in thread "main" java.lang.UnsatisfiedLinkError: no GL in java.library.path: C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include despite I really got a GL folder under the include dir.
>
>
>
> So I got back to Sundararajana samples on github to generate the bindings and got stuck by a surprising JExtract exception :
>
> PS C:\Users\Martin\Dev\jzy3d\external\panama-jextract-samples\opengl> ./compile_windows.ps1
> [...]
> freeglutPath: C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32
> WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract
> C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32\include\stdlib.h:360:47: error: expected ';' after top level declarator
> ERROR: jextract exited with non-zero exit code: 3
>
> Whereas I can not see anything wrong in stdlib.h which is as follow around line 360 :
>
> 358: #ifndef _CRT_TERMINATE_DEFINED
> 359: #define _CRT_TERMINATE_DEFINED
> 360: void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN;
> 361: void __cdecl __MINGW_NOTHROW _exit(int _Code) __MINGW_ATTRIB_NORETURN;
>
> I should mention that
> - I built and installed freeglut since JExtract command for Windows wants it. I verified I could build and run a simple program showing a triangle so I think that my Freeglut install in MinGW64 is correct.
> - I verified GCC and G++ are callable from Powershell
> - The internet sometime suggest to enclose such problematic lines in a #if defined __cplusplus / #endif block but I think I should not have to edit stdlib.h myself.
>
> Is this stdlib error something some of you already faced? How did you fix?
>
> Thanks!
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> Le lundi 18 octobre 2021 à 11:29, Rado Smogura <mail at smogura.eu> a écrit :
>
>> Hi Martin,
>>
>> Let me answer the last questions about JExtract and .h files for every
>>
>> platform.
>>
>> It may be needed to do separate bindings, unless you can prove
>>
>> otherwise. The specifications provides .h files and names, but may not
>>
>> be clear if,
>>
>> - given name is variable, or define
>> - values set to const / variable
>> - expr() is method or define
>>
>> There was one experiment with POSIX, where even so standard things like
>>
>> net may differ on values assigned to DEFINED between Linux & OSX.
>>
>> Roughly speaking GL_CONST_X can be 1 on one system and 2 on the other,
>>
>> and this values will be "inlined" into extracted code.
>>
>> However how exactly is with OpenGL I don't know.
>>
>> Kind regards,
>>
>> Rado
>>
>> On 17.10.2021 15:20, Martin Pernollet wrote:
>>
>>> 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://urldefense.com/v3/__https://github.com/jzy3d/panama-gl__;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8bHkQ00p$
>>>
>>> [1] https://urldefense.com/v3/__https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html__;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8ROseeEa$
>>>
>>> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl__;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8WkFrawU$
More information about the panama-dev
mailing list