Two calls may be required. Two calls doesn’t hurt. Sounds like two calls to me.
1 Like
Also, should we bump to LWJGL3 version 3.2.1 ? It released two days ago.
Currently jme uses version ‘3.1.6’
1 Like
According to Spasi, LWJGL 3 does not (officially) support AWT/Swing integration. Shouldn’t jME also drop support to AWT/Swing instead of trying a workaround?
Perhaps the settings window could be changed to a GLFW window with some stuff done with Nifty or Lemur?
What settings would you use to start that window?
Idk, maybe some default settings like a 640x480 window with the current video refresh rate. Not sure.
I’m not at home today, but I’ll try to think on something tomorrow and show the code here.
The problem is that you’d have to have started up the app first.
So what you are suggesting is basically a total refactoring of the application related classes and system startup on desktop systems.
…as opposed to just taking advantage of the unofficial support (ie: really means bugs that they can’t be bothered to fix)
I guess their suggestion would be JavaFX? That is a more realistic option than totally rewriting all of the app startup stuff to handle a two phase app startup.
Also I thought to add this here.
For me on LWJGL2 when an animated character shows up for this first time in front of camera scene rendering halts for a fraction of time, but after I switched to LWJGL3 this pause time reduced a lot.
Hmm, never seen that option before. Thanks for mentioning it up. Will take a look at it later. It looks it will surely reduce the pause time.
But alongside that I think in LWJGL3 it is because of jemalloc memory allocator that it loads faster.
Why can’t one of us, or I, just make a jfx window and be done with it? Is this a viable option or is it not as simple as I am presuming? What are the implications of a direct port?
I think we should still go ahead and work around the lwjgl3 bug… even if someday we change our settings dialog to JavaFX.
After all, some applications (like mine) may want to pop-up a Swing window before launching the app for other reasons. I shouldn’t be forced to switch to JavaFX just to work around an lwjgl3 bug if there is an easy work-around.
Afaik lwjgl3 and jfx does not work on osx. can’t search the issue on github.
I have a jfx launcher for spoxel on OSX. I haven’t had any issues…
Is this about the flags you need on OSX? -XstartOnFirstThread?
BUT JavaFX is phased out by oracle sometime and for arm it already is for multiple years iirc.
This means one has to install openJFX (the openJDK Port) as well, even for oracle jvms.
I don’t have the source for that information at hand but I thought it was like that and that has to be considered as well.
It may no longer be supported directly by oracle, but there is still a lot of development around jfx. There are ‘arm’ builds out there for the current version for example. With how Oracle’s licensing has changed i’m not sure how many people are going to ship with an Oracle JVM as apposed to openjdk or another open source jvm anyways.
JavaFX is quite alive and well. It’s doing better now than it has in years since it’s part of OpenJDK and actually getting some developer attention now. You don’t need to install it - you just need to pull it into your project with Gradle/Maven/whatever.
1 Like
Source of that information:
https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates
JavaFX is no longer on the JDK, it’s a separate download now. Its development is now on the hands of the OpenJFX community, which includes Oracle.