Re: GLJPanel for LibGDX JOGL backend
Posted by adam_law on Jul 13, 2015; 1:23pm
URL: https://forum.jogamp.org/GLJPanel-for-LibGDX-JOGL-backend-tp4034741p4034880.html
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
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.
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.
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
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.
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.
We have the Android SDK in our environments, we could do the testing, if you want, just tell us what to do :)
Thanks again for the excellent work!
URL: https://forum.jogamp.org/GLJPanel-for-LibGDX-JOGL-backend-tp4034741p4034880.html
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
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.
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.
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
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.
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.
We have the Android SDK in our environments, we could do the testing, if you want, just tell us what to do :)
Thanks again for the excellent work!
| Free forum by Nabble | Edit this page |