Posted by adam_law on Jul 11, 2015; 11:17pm
URL: https://forum.jogamp.org/GLJPanel-for-LibGDX-JOGL-backend-tp4034741p4034868.html

Thanks gouessej :)

Personally, I think it's just that most people are not aware of it. Up to the point where you pointed out that LWJGL was not your work, but a rival's, I thought contributors were all working on the one backend, and this thought process led me here, after following the online trail of potential solutions.

When I first ran our app as JoglApplication, I was surprised; surprised that there were now 2 branches to run a desktop app , and both work as well, on the surface, as the other. There were some slight visual differences, and I must admit that running under JOGL, things look crisper, apart from the startup "hiccup" I mentioned early on, I feel I'd prefer to use the Jogl backend.

Most of the literature on the LibGDX wiki, and code samples all launch from an LWGL-based container. Perhaps getting someone on their side to append a header or footer that links to the JOGAMP classes, or, better yet, alternate samples using the JOGAMP backend, would see people using it more.

Not wanting to be ignorant as I was when I first came here, I read up on some of the history between your rival implementations. JOGL seems to have an unbroken line of development; both JOGL and LWJGL have impressive histories of usage, but LWJGL seems to have broken off their design trajectory going into version 3, citing difficulties in implementing future plans on the previous code-base. With such a wealth of info, someone choosing between backends would have compelling reason to choose, instead of opting for what's prominent in the documentation/wiki.

Idk, it may just be me, but I think most LibGDX (and other framework users), implement some sort of level editor, or simulator, on the desktop. From what I can tell, most have to do it in Swing, or design a UI from the ground up, like Spine (according to their docs), in order to integrate a created app. Swing has served me well over the years, but since I've started using JavaFX 2, now 8, it is now my preferred UI toolkit for Java; it's just so far ahead.

I think the reason why you, or the other experts in the field I've talked to, don't see this as anything significant in the big picture, is because you all have a wealth of options and knowledge that make JavaFX insignificant :)) I mean, from all the conversations I've had, the most common line I got back was "I haven't used JavaFX yet" or "I've used it, but I already have a UI toolkit I made myself." The rest of us humans either aren't us prolific, or are constrained by time and minimal resources. Leveraging what's available is the norm for people like me, and things like what you're doing here right now, is a huge boon :D

For this reason, if this succeeds, I can imagine an uptick in demand for the JOGAMP backend, once LibGDX people realize, as we have, what can be done with a JavaFX UI and an OpenGL display. I would think this will hold true for other frameworks with JOGAMP support, not just LibGDX, if this were made part of their set of options. As far as I can tell, your work on GLJPanel is the only embeddable component that SwingNode can carry to display OpenGL. Barring Oracle bridging the gap themselves, it looks to be the best option avaliable.

Anyway, you have the gratitude of at least 20 people that make up my team. That should count for something, I hope