Posted by adam_law on Jul 08, 2015; 2:59pm
URL: https://forum.jogamp.org/GLJPanel-for-LibGDX-JOGL-backend-tp4034741p4034845.html

I actually read that as part of my search that led me here. It drove point home regarding having few viable options for integrating with JavaFX. Of the strategies mentioned there, it seemed SwingNode was the "easiest" solution, albeit, with a likely performance cost.

Since our application, in desktop mode, isn't one that requires heavy effects and snappy performance at all times, the solution was the one we were looking for. In this mode, it functions more to administer or design, than actual play, which is why we wanted to leverage JavaFX. Once the simulation commences, the JavaFX components take a backseat, and we can then put the rendering system within something like a JoglFrame or as a JoglApplication, the rest of the way.

I hope that it works as well XD Even if it doesn't perform as well as if it were launch "natively" it'd be godsent if all aspects display correctly. On the PoC projects, certain stuff don't show, such as FBO-based lighting and shadow, to name one.

May I ask, based on what I've seen in the backend source, and while working on it, I noticed that these components inherit, or supply the part of the Gdx context, such as input, IO, audio etc. Does this mean that we don't have to use an intermediate input scheme to capture JavaFX events and translate it down to Gdx? On the Aqd project, and it's parent project, there was a class called XpefInput that did this translation. It shouldn't be a problem translating this to capture from SwingNode, but I was just curious if this translation need be made, or not.

Thanks :)