Posted by gouessej on Jul 13, 2015; 1:54pm
URL: https://forum.jogamp.org/GLJPanel-for-LibGDX-JOGL-backend-tp4034741p4034884.html

adam_law wrote

Thank you so much, gouessej!  I wish we knew about the Ardor3D project back when we first started this.  At least, we know now :)

We're about a month or so from releasing our app (not integrated into the JavaFX UI) for testing, so it's a little late in the game to make a switch XD

You're welcome :) I understand your constraints. Next time, think about it twice before assuming that JavaFX/OpenJFX is easy to use with the rest of the Java world ;)

adam_law wrote

It took about 10 minutes to figure out the new additions. What we ended up doing is creating a new class in the backend
to just have the GLJPanel, w/o the Frame. It may be because we don't know the proper configuration but we couldn't JoglSwingApplication because it automatically made a Frame, or if we set it to full screen, it took up the screen before we could render it to the JavaFX UI.

Sorry, that's my fault. I can't do anything completely "alien", I mean that it just follows how the API is expected to work, even JoglSwingGraphics expects a JFrame. However, I can look at other backends and see how to ease your use case. I will create JoglSwingCanvas (like JoglNewtAwtCanvas).

adam_law wrote

There were then a couple of ClassCastExceptions, because there attempts to cast to Newt classes in the JoglGraphicsBase in method display(). Changing those casts to our custom class (for graphics), and JoglAWTInput, got things to work.

Thank you for the feedback, you're right:
https://github.com/gouessej/libgdx/blob/master/backends/gdx-backend-jogamp/src/com/badlogic/gdx/backends/jogamp/JoglGraphicsBase.java#L159
https://github.com/gouessej/libgdx/blob/master/backends/gdx-backend-jogamp/src/com/badlogic/gdx/backends/jogamp/JoglGraphicsBase.java#L162
I will fix it in a few hours.

adam_law wrote

We now have our application running from SwingNode, at about 18 - 22 FPS, displaying stuff correctly and input seems fine :) In AqD's/Spasi's projects, stuff like Box2Dlights either don't show, or made the entire rendering go gray. They still utilized what they use during the rendering process, however. Also, the JavaFX behavioral stuff for our UI, like interpolation, rotation, scaling and fades, is now snappier

It's better than nothing, I'm glad for you.

adam_law wrote

There are a couple of things I'm hoping you'd know. Would this be the expected FPS moving forward, or are there ways to improve it? We only launched using the default JoglAWTConfiguration settings. One good thing about the AqD's JavaFX PoC, is that we had about 62 FPS on our Windows-based environment, though it didn't draw things correctly at times.

One month is a bit short to investigate. I see no trivial or obvious way of improving the performance yet. Do you force the use of OpenGL ES within JavaFX/OpenJFX under Windows? If I were you, I would carefully tinker to get a faster result.

adam_law wrote

Secondly, there seems to either be a memory leak, or there is something that's driving the heap usage up. This was true even in the JavaFX integration attempts such as the project made by AqD and Spasi. The heap usage in the latter was fast, in the JoglSwingPanel we're now testing, not so fast, but it does grow to a large #, if left alone. We'll profile and see if it really is a memory leak.

GLJPanel has an higher memory footprint than other available options (GLCanvas, GLWindow, ...). Sorry to ask you this but would you mind sharing your JoglSwingPanel so that I might find the culprit?

adam_law wrote

We have the Android SDK in our environments, we could do the testing, if you want, just tell us what to do :)

There is something else preventing us from running the tests, LibGDX can't find the directory called "data/".

adam_law wrote

Thanks again for the excellent work!

You're welcome :) You should loudly say on Github and on the official LibGDX forum that you use the JogAmp backend with JavaFX/OpenJFX, it would help me to find some contributors.