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

gouessej wrote

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 ;)

:)) That's really funny! Man, I didn't think about it at all, but you're absolutely right. I don't know if that's the intention Sun had from the start, but since Oracle took charge, it does seem that they're not very "open doors" about JavaFX. It has good intentions with its scene graph, but it's still nowhere near the advancements made on your (OpenGL) ends. Though I think they're trying to make inroads by opening up to the top 3 mobile platforms? Still, like someone said to me elsewhere, when Oracle will decide to do something, the rest of the world would have moved on.

gouessej wrote

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).

No problem at all. As I've said, it didn't take long to figure it out. A canvas sounds about right, I think on the "main" backend for LibGDX, they've provided a Swing Window, a Canvas, and GLWindow, so I guess the only thing "missing" in the JOGAMP backend is the canvas.

gouessej wrote

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.

I didn't. I thought about it, but opted to do a "vanilla" run. That's a good tip, however, I'll check on it ASAP.

gouessej wrote

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?

Of course! It's nothing more than a trimmed down JoglSwingApplication :) (It's kind of embarrassing, now that I think about it :)) )

http://pastebin.com/jRueRpQ0

gouessej wrote

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

I'll try to see if I can figure out what's going on.

gouessej wrote

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.

Of course. I could do it now, or would you rather until the memory and FPS issues are checked out further?

Thanks.

Edit: Ach. Can't do the profiling it seems, at least not on VisualVM. The time it takes to hook up to the app, and run profiling, makes something choke on the Swing -> FX thread. I'll try finding something that works, maybe Plumbr, or something else out there.

Edit 2: I forgot to share the modified JoglSwingGraphics code, to save you the time :)
http://pastebin.com/sCxHwnUk

Edit 3: Setting the order to es2, sw made the memory issue worse, even more so than the JavaFX PoCs. Using the order of es2, es1, sw, yielded the same, but it looked better :)) e.g. the shaders in Box2dLights came out with the right color, and got about 2 frames in speed. Not setting the order it made it more stable. On a side note, I did set the app to force gpu usage, and it turned out to be the best display (still at 18-21 FPS)