Generating a common interface for multiple platform specific binding

Martin Pernollet martin.pernollet at protonmail.com
Fri Jan 6 12:11:42 UTC 2023


Le vendredi 6 janvier 2023 à 12:15, Maurizio Cimadamore a écrit :

> Really good progress!
>
> Do you think that that the same set of bindings will not work across OS? Why?
>
>>

For the reasons you previously mentioned :) But assuming the type differences are hidden by GL API, maybe there will be no difference. When back on Linux and Windows, I'll check if I can use bindings generated with my macOS and will tell you.

In addition to a potential variation between OS, there are variation between the OpenGL versions supported on each computer. The computer generating the bindings may support OpenGL 4.6 and generate bindings for this version, which won't be compatible with another older macOS supporting say OpenGL 3.

> Other options, if you are into classfile manipulation are:
>
> * ASM (perhaps the more popular, what the JDK itself uses): https://asm.ow2.io/
>
> * the brand new JDK classfile API: https://mail.openjdk.org/pipermail/classfile-api-dev/2022-June/000000.html

Thank you! The classfile API looks interesting but still at the draft status, so I'll rather go for ASM.

>> To answer the "well-behave" nature of OpenGL
>>
>> - Yes, there are types to hide differences per platform. OpenGL is an API so one can expect to find the same headers everywhere.
>> - BUT OpenGL has dynamic loading capabilities to allow getting features on computers that have hardware (GPU) supporting some kind of rendering, and others not able to do the same, still running on the same OS but not the same GPU. That is a very interesting case for Panama. In that case I'll have to rely on OpenGL API methods that load functions only if they are supported on the host computer.
>
> I think you refer to GL extensions - aren't there like opaque function pointers whose existence you can query dynamically?

Yes!

> That said, the fact that there are extensions, doesn't mean that the jextract bindings would not be portable across OSs ? But more that you need to write some kind of support to discover and invoke the extension functions? (wild guess here)

Exactly!

>> A bit more about OpenGL
>>
>> - Sometime I have to ask the OS to do things such as executing java runnable on the main macOS thread. For now this requires I keep using manually generated binding from JOGL, allowing to use Objective C code. [I don't think JExtract can do this](https://urldefense.com/v3/__https://github.com/manuelbl/JavaDoesUSB/issues/5__;!!ACWV5N9M2RV99hQ!Kml55Ybj-rpsn3N8SEjStiscqW8Ma0NJklvvm_C6lYscfvg2Y8qEDk_fJLbitlLqV4ZvtoW5kfz9q_NBqkWJJWQNXyD0UYfPT9ePYA$).
>
> Does passing this option " -XstartOnFirstThread" to the JVM works? IIRC, it was added for things like these.

Yes it does. However JOGL & LWJGL took a different approach. LWJGL required it, while JOGL does the necessary things so that it is not needed to start the JVM on the first thread to have OpenGL properly working. I'd like to follow the JOGL approach which makes the usage more straightforward (but my dev more complex :)

Thank you for your time and attention Maurizio!

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230106/45c3e74c/attachment-0001.htm>


More information about the panama-dev mailing list