Re: GLJPanel for LibGDX JOGL backend
Posted by
gouessej on
Jul 13, 2015; 3:01pm
URL: https://forum.jogamp.org/GLJPanel-for-LibGDX-JOGL-backend-tp4034741p4034886.html
adam_law wrote
:)) 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.
Oracle will implement an equivalent of JAWT for JavaFX/OpenJFX in Java 1.9, it will help us to provide an equivalent of GLJPanel for JavaFX/OpenJFX. In the meantime, it's a waste of time to me. The JavaFX 3D API seems to be a bit better than Java3D but it has the same caveats than its older versions...
adam_law wrote
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.
The difference is that their AWT support is worse and they have no equivalent of GLJPanel actually. They call their classes "Swing*whatever" but they use only AWT classes under the hood.
adam_law wrote
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.
You should look at all tips in the bug report about JavaFX/OpenJFX and JOGL, I probably forget some of them. Aqd's advices at the very end is very important under Windows.
adam_law wrote
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
I'll look at it carefully at home and I'll see what I can do.
adam_law wrote
I'll try to see if I can figure out what's going on.
Thanks. Maybe it comes from the Gradle build, I have to add a few things into it.
adam_law wrote
Of course. I could do it now, or would you rather until the memory and FPS issues are checked out further?
As you wish. The solutions based on other APIs have some performance problems too anyway.
adam_law wrote
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/sCxHwnUkEdit 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)
Check that it really finds the ES2 native libraries under Windows as they aren't shipped by default as Aqd explained. Yes :s :(