<div style="font-family: Arial; font-size: 14px;"><span style="display:inline !important">Sorry, I forgot the video attachement.</span><br></div><div style="font-family: Arial; font-size: 14px;"><br></div><div class="protonmail_quote">
------- Original Message -------<br>
Le vendredi 6 janvier 2023 à 11:31, Martin Pernollet <martin.pernollet@protonmail.com> a écrit :<br><br>
<blockquote class="protonmail_quote" type="cite">
<div style="font-family: Arial; font-size: 14px;">Hi everyone,</div><div style="font-family: Arial; font-size: 14px;"><br></div><div style="font-family: Arial; font-size: 14px;">Thank you a lot for your messages. I got good news to share :</div><div style="font-family: Arial; font-size: 14px;"><ul><li><span>First, I have been able to render the OpenGL teapot <i>inside</i> a Swing and AWT window \o/ Please see the video attached or even try it <a title="on your macOS here" href="https://gitlab.com/jzy3d/panama-gl/-/blob/main/panama-gl-wrappers-macos/src/main/java/demos/panamagl/macos/swing/DemoTeapot_Onscreen_macOS.java" rel="noreferrer nofollow noopener" target="_blank">on your macOS here</a>.</span></li><li style="font-family: Arial; font-size: 14px;">Second, I confirm that I running bindings generated for macOS 10.15 runs on 10.12. </li></ul><div><br></div></div><div style="font-family: Arial; font-size: 14px;">The pattern I am going toward for a common interface</div><div style="font-family: Arial; font-size: 14px;"><ul><li>Have generated bindings, generated once and deployed as<a title="standalone maven artifacts" href="https://gitlab.com/jzy3d/panama-gl-bindings" rel="noreferrer nofollow noopener" target="_blank"> standalone maven artifacts</a>.</li><li>Have <a title="wrappers of these bindings" href="https://gitlab.com/jzy3d/panama-gl/-/blob/main/panama-gl-wrappers-macos/src/main/java/opengl/macos/GL_macOS_10_15_7.java" rel="noreferrer nofollow noopener" target="_blank">wrappers of these bindings</a> implementing a <a title="common interface" href="https://gitlab.com/jzy3d/panama-gl/-/blob/main/panama-gl-core/src/main/java/opengl/GL.java" rel="noreferrer nofollow noopener" target="_blank">common interface</a>. <br></li></ul></div><div style="font-family: Arial; font-size: 14px;"><br></div><div style="font-family: Arial; font-size: 14px;">I will generate the common interface and the wrappers. I am thinking of using <a title="Javaassist" href="http://www.javassist.org/" rel="noreferrer nofollow noopener" target="_blank">Javaassist</a>. I am interested if you have other suggestions.</div><div style="font-family: Arial; font-size: 14px;"><br></div><div style="font-family: Arial; font-size: 14px;">To answer the "well-behave" nature of OpenGL</div><div style="font-family: Arial; font-size: 14px;"><ul><li><span>Yes, there are types to hide differences per platform. OpenGL is an API so one can expect to find the same headers everywhere.</span></li><li><span>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.</span></li></ul></div><div style="font-family: Arial; font-size: 14px;"><br></div><div style="font-family: Arial; font-size: 14px;">A bit more about OpenGL</div><div style="font-family: Arial; font-size: 14px;"><ul><li>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. <a title="I don't think JExtract can do this" href="https://github.com/manuelbl/JavaDoesUSB/issues/5" rel="noreferrer nofollow noopener" target="_blank">I don't think JExtract can do this</a>.</li><li>There are several additional libraries to GL and GLUT, handling OS specific things (e.g. CGL for mac, WGL for windows, GLX for linux). I'll most probably bind to these rather than glut. </li></ul></div><div style="font-family: Arial; font-size: 14px;"><br></div><div style="font-family: Arial; font-size: 14px;">The JavaDoesUSB project is really great and its developer has been really nice by providing help on JExtract, thank you for the advice! </div>
<div style="font-family: Arial; font-size: 14px;" class="protonmail_signature_block">
<div class="protonmail_signature_block-user protonmail_signature_block-empty">
</div>
<div class="protonmail_signature_block-proton"><br></div></div><div class="protonmail_quote">
------- Original Message -------<br>
Le mardi 3 janvier 2023 à 18:51, Maurizio Cimadamore <maurizio.cimadamore@oracle.com> a écrit :<br><br>
<blockquote type="cite" class="protonmail_quote">
<p><br>
</p>
<div class="moz-cite-prefix">On 20/12/2022 15:04, Martin Pernollet
wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family: Arial; font-size: 14px;">Here's my use
case in more detail : I've been advised to generate <b>different
binding for different OS</b> (and maybe version). For OpenGL,
this lead me to a glut_h binding for macOS, one for Windows and
one for Linux.</div>
</blockquote>
<p>Expanding a bit more on this point (apologies if my previous
reply was not clear).</p>
<p>While we suggest that, in the general case, one might have to run
jextract multiple times (once per target platform), your mileage
my vary.</p>
<p>Consider the jextract code. Jextract relies on libclang, a native
library. For jextract itself, we just generate a single copy of
the bindings for both MacOS, Linux and Windows:</p>
<p><a target="_blank" rel="noreferrer nofollow noopener" class="moz-txt-link-freetext" href="https://github.com/openjdk/jextract/tree/master/updateclang">https://github.com/openjdk/jextract/tree/master/updateclang</a></p>
<p>This is possible because libclang has been written in a portable
way: for instance types that are platform dependent such as `long`
have been expanded to `long long`, so that they are 64 bits no
matter what.</p>
<p>Also, the API makes extensive use of the opaque handle pattern:
that is, a lot of libclang data structures are built inside the
library itself, and then returned to clients as opaque by-value
structs, whose contents point to the memory allocated by the
library.</p>
<p>As such, the layouts of the structs defined in libclang is never
truly important, as a client will typically pass them opaquely to
other functions.</p>
<p>The combination of these two factors allow the bindings to work
seamlessly across platforms.</p>
<p>Now, while I'm not an expert on OpenGL, I seem to recall that
OpenGL is rather well-behaved when it comes to defining new types
- e.g. it defines its own primitives (GLint, GLfloat and such).
This gives me some hope that the OpenGL bindings might, in fact,
work well across multiple platforms. <br>
</p>
<p>One complication with OpenGL is GLUT, which doesn't seem (IIRC)
to be well supported on some platforms (e.g. MacOS). So, some
tricks might be necessary there.</p>
<p>I guess the main takeaway there is that IF (big if :-)) the
library has been written in a portable way, then a single jextract
run might be all you need (maybe with some filtering added on top
to get rid of platform-dependent functionalities, which you can do
with the jextract options already available).</p>
<p>The USB code [1] I pointed you at, on the other hand, is much
more complex, as that code needs to interface with _different_
libraries to do its job on different platforms - so of course that
kind of unification is not something you can achieve using a tool.</p>
<p>So, as often is the case with native code, we have a spectrum of
"badness":</p>
<p>1) well-behaved libraries (like libclang and OpenGL), which are
written with portability in mind<br>
2) libraries that are mostly portable, but might present minor
mismatches (e.g. long being 64 vs. 32 bits, some API points not
available in all platforms, etc.)<br>
3) libraries that are hopelessly platform-specific</p>
<p>I believe jextract proves that (1) already works (**). And for
(3), as stated, not much can be done.</p>
<p>So the question is whether something should be done for (2) - and
how much can be done "automagically". This will likely require us
to come up with a precise definition of the boundaries of what
gaps we can actually bridge, as (2) is a rather fuzzy bucket.<br>
</p>
<p>(**) I can see ways in which even libraries in bucket (1) could
fail - e.g. this can happen because the symbol lookup would fail
to initialize because of different library names/paths. This is
something that we need to address, but also something which
requires a much much smaller hammer (such as the ability to define
your own symbol lookup).<br>
</p>
<p>Cheers<br>
Maurizio<br>
</p>
<p>[1] - <a target="_blank" rel="noreferrer nofollow noopener" class="moz-txt-link-freetext" href="https://github.com/manuelbl/JavaDoesUSB">https://github.com/manuelbl/JavaDoesUSB</a><br>
</p>
</blockquote><br>
</div>
</blockquote><br>
</div>