GLJPanel for LibGDX JOGL backend

adam_law wrote

Thanks gouessej :)

You're welcome.

adam_law wrote

Personally, I think it's just that most people are not aware of it. Up to the point where you pointed out that LWJGL was not your work, but a rival's, I thought contributors were all working on the one backend, and this thought process led me here, after following the online trail of potential solutions.

When I first ran our app as JoglApplication, I was surprised; surprised that there were now 2 branches to run a desktop app , and both work as well, on the surface, as the other. There were some slight visual differences, and I must admit that running under JOGL, things look crisper, apart from the startup "hiccup" I mentioned early on, I feel I'd prefer to use the Jogl backend.

Most of the literature on the LibGDX wiki, and code samples all launch from an LWGL-based container. Perhaps getting someone on their side to append a header or footer that links to the JOGAMP classes, or, better yet, alternate samples using the JOGAMP backend, would see people using it more.

Not wanting to be ignorant as I was when I first came here, I read up on some of the history between your rival implementations. JOGL seems to have an unbroken line of development; both JOGL and LWJGL have impressive histories of usage, but LWJGL seems to have broken off their design trajectory going into version 3, citing difficulties in implementing future plans on the previous code-base. With such a wealth of info, someone choosing between backends would have compelling reason to choose, instead of opting for what's prominent in the documentation/wiki.

The LibGDX maintainers don't want to put our backend into the official version. Therefore, it will always be a kind of outsider. Moreover, it will compete not only with a typical backend for the desktop environment, it will become usable in embedded environments too, it questions their design choices :) If the JogAmp backend was used, LibGDX would need to keep only 2 backends as our stuff can't replace GWT (yet?).

adam_law wrote

Idk, it may just be me, but I think most LibGDX (and other framework users), implement some sort of level editor, or simulator, on the desktop. From what I can tell, most have to do it in Swing, or design a UI from the ground up, like Spine (according to their docs), in order to integrate a created app. Swing has served me well over the years, but since I've started using JavaFX 2, now 8, it is now my preferred UI toolkit for Java; it's just so far ahead.

I find this 2D API used in Spine really great by the way. If we could do the same thing in JOGL, it would be awesome and we could advise the developers to switch to NEWT without using any bridges except for legacy code and third party libraries. OpenJFX/JavaFX has numerous advantages (including the chart API) but its drawbacks forced numerous software publishers to stick or to go back to Swing.

adam_law wrote

I think the reason why you, or the other experts in the field I've talked to, don't see this as anything significant in the big picture, is because you all have a wealth of options and knowledge that make JavaFX insignificant :)) I mean, from all the conversations I've had, the most common line I got back was "I haven't used JavaFX yet" or "I've used it, but I already have a UI toolkit I made myself." The rest of us humans either aren't us prolific, or are constrained by time and minimal resources. Leveraging what's available is the norm for people like me, and things like what you're doing here right now, is a huge boon :D

I have used OpenJFX/JavaFX a bit but in terms of interoperability, it looks like the first years after AWT was born. I have some strong time constraints at work too, I used Eclipse RCP, Netbeans Platform, SWT and mainly Swing. The problem is that it's up to Oracle to provide a public API to encourage the developers of third party libraries to work with OpenJFX/JavaFX on the long term. Maybe what I did won't work with OpenJFX/JavaFX.

adam_law wrote

For this reason, if this succeeds, I can imagine an uptick in demand for the JOGAMP backend, once LibGDX people realize, as we have, what can be done with a JavaFX UI and an OpenGL display. I would think this will hold true for other frameworks with JOGAMP support, not just LibGDX, if this were made part of their set of options. As far as I can tell, your work on GLJPanel is the only embeddable component that SwingNode can carry to display OpenGL. Barring Oracle bridging the gap themselves, it looks to be the best option avaliable.

Despite my opinion about OpenJFX/JavaFX, I want to make it work with LibGDX. I remind you that JogAmp's Ardor3D Continuation already works with OpenJFX/JavaFX :) In my humble opinion, the best available option would be a UI toolkit within NEWT able to compete with Swing and JogAmp Scenegraph API is a good start.

adam_law wrote

Anyway, you have the gratitude of at least 20 people that make up my team. That should count for something, I hope

Yes it counts but we still have some work to do to make it work. Next time, please ensure that what you want to do is achievable ;) If we fail, maybe you'll have to consider using the poor JavaFX 3D API.

I have fixed a few regressions but I can't test my stuff because LibGDX Gradle build demands me to install the Android SDK which I don't want to do. Therefore, I can't use it to open the sub-projects "cuboc", "invaders", ... The sub-project "gdx-tests" is unable to find the files in the directory "data/". Therefore, all tests fail.

I have committed my changes. I don't know how I will test them successfully.

gouessej wrote

I have fixed a few regressions but I can't test my stuff because LibGDX Gradle build demands me to install the Android SDK which I don't want to do. Therefore, I can't use it to open the sub-projects "cuboc", "invaders", ... The sub-project "gdx-tests" is unable to find the files in the directory "data/". Therefore, all tests fail.

I have committed my changes. I don't know how I will test them successfully.

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!

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.

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)

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

Check that it really finds the ES2 native libraries under Windows as they aren't shipped by default as Aqd explained. Yes :s :(

gouessej wrote

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

Ah. Very good indeed. September 2016 is a bit far off and I think any real work based off it will start to come out in 2017. But you're right, and I think everyone else in this part of the industry feels the same way (which explains all those "I haven't bothered with JavaFX yet." replies I got haha).

gouessej wrote

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.

I was just about to say most of the very same things :)) Especially the GLJPanel part. I'm just wondering, because I don't know anyone working in the LibGDX team personally, is it because there're LWJGL members there that LWJGL is the de facto standard there? Just curious.

gouessej wrote

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.

Yeah, I figured as much. I went back to that article before coming back here to right this. I was tracing the process where the GLCaps were being set, and it does fail on setting ES2 (I set it to try for ES2 before failing to GL2).

gouessej wrote

As you wish. The solutions based on other APIs have some performance problems too anyway.

I did post on the ticket I opened on Git, though it was already closed when I got there.

I didn't want to add more to your plate, but you might want to know about an error that pops up every now and then during our tests.

http://pastebin.com/K4TJi6Sg

Thanks.

adam_law wrote

Ah. Very good indeed. September 2016 is a bit far off and I think any real work based off it will start to come out in 2017. But you're right, and I think everyone else in this part of the industry feels the same way (which explains all those "I haven't bothered with JavaFX yet." replies I got haha).

Coding against a private API subject to changes would be a waste of time and actually, there isn't an high demand of interoperability with JavaFX/OpenJFX yet.

adam_law wrote

I was just about to say most of the very same things :)) Especially the GLJPanel part. I'm just wondering, because I don't know anyone working in the LibGDX team personally, is it because there're LWJGL members there that LWJGL is the de facto standard there? Just curious.

JOGL was used by default in the past in LibGDX several years ago. A few L**** seemed to lead a FUD campaign against JOGL just after Oracle abandoned it, they claimed that JOGL was dead and it was used by a lot of developers to stop supporting it in their frameworks. However, some corporations came back and the great commitment of several people in our community has helped a lot to show that JogAmp is solid.

adam_law wrote

Yeah, I figured as much. I went back to that article before coming back here to right this. I was tracing the process where the GLCaps were being set, and it does fail on setting ES2 (I set it to try for ES2 before failing to GL2).

You'll have to provide the native libraries :s

adam_law wrote

I did post on the ticket I opened on Git, though it was already closed when I got there.

I didn't want to add more to your plate, but you might want to know about an error that pops up every now and then during our tests.

http://pastebin.com/K4TJi6Sg

Thanks.

Try using the option that forces JavaFX/OpenJFX and Swing to use the same event dispatch thread. Set it very early when running your application, pass it to the JVM.

By the way, I'm fixing the class cast exception you mentioned and the rest...

gouessej wrote

Coding against a private API subject to changes would be a waste of time and actually, there isn't an high demand of interoperability with JavaFX/OpenJFX yet.

It's easy to see why, it has such potential though, but people have been saying that since before 2010 :))

gouessej wrote

JOGL was used by default in the past in LibGDX several years ago. A few L**** seemed to lead a FUD campaign against JOGL just after Oracle abandoned it, they claimed that JOGL was dead and it was used by a lot of developers to stop supporting it in their frameworks. However, some corporations came back and the great commitment of several people in our community has helped a lot to show that JogAmp is solid.

I did come across some that when I went to familiarize myself with the history. Glad that it's quieted down now. On a side note, I also read a post you contributed to in LibGDX. I think they said that be willing to put Jogamp on the same exposure level as the other backend, if contributions keep in pace with their releases, along with documentation. However, I know that your focus for Jogamp goes beyond the gaming applications, but I think that may be the reason why the other backend saw more exposure. Reading up on Jogamp, it's being used on numerous fields, if one looks up the other binding project, it's almost exclusively used in gaming, and these associations stuck.

gouessej wrote

You'll have to provide the native libraries :s

Yeah, confirmed it by looking at the verbose output for Prism. I'm about to start creating that jfxrt.jar specified in Aqd's instructions.

gouessej wrote

Try using the option that forces JavaFX/OpenJFX and Swing to use the same event dispatch thread. Set it very early when running your application, pass it to the JVM.

I tried that early on, but it had an undesired effect. FrameBuffer objects (I'm not sure if all) aren't displayed at all, e.g. Box2dLights objects don't show. I'm not sure if its related, but in the Spasi project, he had to put in a means to defer rendering, for things to sync up (he did it after Aqd forked for a Jogl attempt).

gouessej wrote

By the way, I'm fixing the class cast exception you mentioned and the rest...

Thanks :) I'm trying to get my current checkout of your LibGDX fork to work in my environment. For some reason, the Jogamp backend along with its tests, does not have the reference to the GDX project, everything else seems to be in order. I'll keep trying.

Edit 1:
Got ES2 to work, but, apparently, something must have changed since the last update of Aqd's project. There was an additional step (or 2) I had to make in order to get it running.

I couldn't work on Jogamp tests issue, I resolved the workspace errors by updating your fork to the latest Gdx snapshot, but the backend itself is now missing; I'm guessing since you're working on it? Unfortunately, the updating also took off the source files I was using, so I'll just wait till you're done, so I can test it with ES2.

adam_law wrote

gouessej wrote

Coding against a private API subject to changes would be a waste of time and actually, there isn't an high demand of interoperability with JavaFX/OpenJFX yet.

It's easy to see why, it has such potential though, but people have been saying that since before 2010 :))

gouessej wrote

JOGL was used by default in the past in LibGDX several years ago. A few L**** seemed to lead a FUD campaign against JOGL just after Oracle abandoned it, they claimed that JOGL was dead and it was used by a lot of developers to stop supporting it in their frameworks. However, some corporations came back and the great commitment of several people in our community has helped a lot to show that JogAmp is solid.

I did come across some that when I went to familiarize myself with the history. Glad that it's quieted down now. On a side note, I also read a post you contributed to in LibGDX. I think they said that be willing to put Jogamp on the same exposure level as the other backend, if contributions keep in pace with their releases, along with documentation. However, I know that your focus for Jogamp goes beyond the gaming applications, but I think that may be the reason why the other backend saw more exposure. Reading up on Jogamp, it's being used on numerous fields, if one looks up the other binding project, it's almost exclusively used in gaming, and these associations stuck.

gouessej wrote

You'll have to provide the native libraries :s

Yeah, confirmed it by looking at the verbose output for Prism. I'm about to start creating that jfxrt.jar specified in Aqd's instructions.

gouessej wrote

Try using the option that forces JavaFX/OpenJFX and Swing to use the same event dispatch thread. Set it very early when running your application, pass it to the JVM.

I tried that early on, but it had an undesired effect. FrameBuffer objects (I'm not sure if all) aren't displayed at all, e.g. Box2dLights objects don't show. I'm not sure if its related, but in the Spasi project, he had to put in a means to defer rendering, for things to sync up (he did it after Aqd forked for a Jogl attempt).

gouessej wrote

By the way, I'm fixing the class cast exception you mentioned and the rest...

Thanks :) I'm trying to get my current checkout of your LibGDX fork to work in my environment. For some reason, the Jogamp backend along with its tests, does not have the reference to the GDX project, everything else seems to be in order. I'll keep trying.

Edit 1:
Got ES2 to work, but, apparently, something must have changed since the last update of Aqd's project. There was an additional step (or 2) I had to make in order to get it running.

I couldn't work on Jogamp tests issue, I resolved the workspace errors by updating your fork to the latest Gdx snapshot, but the backend itself is now missing; I'm guessing since you're working on it? Unfortunately, the updating also took off the source files I was using, so I'll just wait till you're done, so I can test it with ES2.

I think that I fixed this issue yesterday. What do you mean? My backend is still in my Github repository, not in the official one.

gouessej wrote

I think that I fixed this issue yesterday. What do you mean? My backend is still in my Github repository, not in the official one.

Yes, that's the one I have. It seemed down for a while, when I tried to rebuild earlier today. The Jogamp backend folder was empty, and Gradle dependencies weren't loaded. But I tried a clean install a few minutes ago, and it's loaded up fine again, so no worries.

BTW, there's a double entry in the pom.xml for <module>backends/gdx-backend-jogamp</module>, which caused the installation to stop until I removed it.

Thanks for all the hard work, it seems like you had a long day XD. Sorry about that.

Edit: Running the JoglSwingCanvas w/ ES2 didn't bring any frame gains, though it does somewhat slow down the heap usage.

Lastly, I don't know if it's LibGDX itself, but after the maven install, and adding the backend to the project, it had a missing dependency under gdx/libs/gdx-natives.jar. I just got it from the nightlies and threw it in the project manually :))

Thank you, I fixed the pom file a few minutes ago. There is still a problem with the Gradle build, it complains about duplicated entries but it doesn't come from my changes this time (I'm almost sure of that). I can't import gdx-tests-jogamp, I can't run my tests, nobody answers to my questions on the official LibGDX forum, it doesn't help.

I think that you'll have to use ES2 and the trick to force OpenJFX/JavaFX to use the same EDT than Swing in the meantime, until Sven gets some proper funding to work on GLJFXPanel when Java 1.9 is ready (and then I'll have to implement JoglJFXCanvas in LibGDX). I'll let you know any possibilities of improving the frame rate and reducing the memory footprint.

Edit.: Oh.... When you build with Gradle, it creates tons of files not ignored by Git...... I made something cleaner in JogAmp's Ardor3D Continuation in order to build without such troubles, I'm a bit fed up, it's not your fault.

gouessej wrote

Thank you, I fixed the pom file a few minutes ago. There is still a problem with the Gradle build, it complains about duplicated entries but it doesn't come from my changes this time (I'm almost sure of that). I can't import gdx-tests-jogamp, I can't run my tests, nobody answers to my questions on the official LibGDX forum, it doesn't help.

I found that there are only certain parts of the day, and certain prominent members, that are responsive on the LibGDX end, and they, more or less, answer only toward their expertise. I may be wrong, but the game development niche breeds a different type of developer, at least on the framework consumer end. Not a lot are helpful, and some are downright condescending :))

Most of my forum posts are ignored, but I found that you can start something in IRC, then carry on in the forums.

gouessej wrote

I think that you'll have to use ES2 and the trick to force OpenJFX/JavaFX to use the same EDT than Swing in the meantime, until Sven gets some proper funding to work on GLJFXPanel when Java 1.9 is ready (and then I'll have to implement JoglJFXCanvas in LibGDX). I'll let you know any possibilities of improving the frame rate and reducing the memory footprint.

ES2 does help, but forcing both Swing and FX threads on the EDT slows it down by a lot. Actually, not really slowing it down, but makes rendering fluctuate from 5 to 20+ FPS, as opposed to not doing it, and things stay stable, though it does throw out that error I made a pastebin about above.  

I'll look forward to any input about improving FPS and memory usage :)

gouessej wrote

Edit.: Oh.... When you build with Gradle, it creates tons of files not ignored by Git...... I made something cleaner in JogAmp's Ardor3D Continuation in order to build without such troubles, I'm a bit fed up, it's not your fault.

:)) I can imagine, I just got out of fixing my own environment from some obscure Eclipse bugs that killed content assistance and the open declaration function XD. With jobs like this, who needs more excitement, eh?

I'm not sure if it's the cause, but your GDX fork has outdated referenced in it's build.gradle file. Xerxes' version works better, I think. Oh, if you haven't come across it before, when the GDX team transitioned to Gradle, they moved people to using their gdx-setup-ui app, for the cleanest possible environment install of their stuff.

Actually, if you set the exclusive thread correctly, you can improve the frame rate and get rid of the nasty exception. Set it in GLEventListener.init() and let me know the results.

You can call animator.setExclusiveContext(true) but there is a risk of deadlock when the animator is used with GLCanvas or GLJPanel.

gouessej wrote

Actually, if you set the exclusive thread correctly, you can improve the frame rate and get rid of the nasty exception. Set it in GLEventListener.init() and let me know the results.

Sorry to only get to this now, I thought you were resting from this case :))

You're right, I actually came around today to tell you that I found out why the FPS was so low when I used -javafx.embed.singleThread=true: I had another instance running XD I guess it's because they're sharing the GPU? Using only one instance at a time has FPS around 18-23, and yes, the exception is prevented.

I'm not sure how to call/use GLEventListener.init()? My instantiation just involves using JoglSwingCanvas and passing JoglSwingCanvas.getCanvas to SceneNode. Do you mean I should do this through the source code?

gouessej wrote

You can call animator.setExclusiveContext(true) but there is a risk of deadlock when the animator is used with GLCanvas or GLJPanel.

Same here? The only animator I can find is from JoglSwingCanvas.getGLCanvas().getAnimator(), but it doesn't have the method.

Sorry for not getting it right away. Thanks for the suggestions!

Sorry for double posting, I just came by to say thank you again for this. We've been very busy with other stuff, especially now that it's possible to integrate our content within our JavaFX perspective (we have several perspectives, other than JFX). It's been overall helpful, and even though the FPS and memory usage issues haven't been addressed yet, it allows us to rapidly move forward with stuff that got bottle-necked.

I'll make a post at SO and other sites stating this as a solution, some time during the weekend.

More power to you all, and thanks again.

If the returned animator is an instance of AnimatorBase (obviously a subclass of it), you can call setExclusiveContext(true) on it.

gouessej wrote

If the returned animator is an instance of AnimatorBase (obviously a subclass of it), you can call setExclusiveContext(true) on it.

Ach. It's been a long day, and I'm not getting it completely :)) So very sorry gouessej, the mind and body are willing, but both are very weak atm.

The only Animator instance I see for JoglSwingCanvas is under JoglSwingGraphics (JoglGraphicsBase), and is protected, with no getter, which was why I was asking if there was a way I'm not seeing, or if I should just go into the source or subclass within the package to make a getter or a stub somewhere.

JoglSwingCanvas extends GLJPanel, you can use create a plain animator (Animator class), call setExclusiveThread(true) on it and add this JoglSwingCanvas into it.