LWJGL v2 versus v3

pspeed · August 7, 2019, 6:11pm

I still say if we have to suck in a whole giant GUI library just for a settings dialog then it’s better to just drop the settings dialog. “Yeah, my blue cube app is 50 meg… but look at that cool settings dialog”, said no one ever.

fba · August 8, 2019, 2:01am

What if we have no settings dialog at all? I mean, as far as I understand, it’s a developer tool supposed to be hidden from end users on release versions of games, am I wrong?

Ali_RS · August 8, 2019, 4:45am

@RiccardoBlb I tried your fix, after I click the “Continue” button, the settings dialog gets closed but the GLFW window never starts and JVM keeps running forever.

Here is the output:

Found main ThreadGroup java.lang.ThreadGroup[name=system,maxpri=10]
Stop Thread[AWT-XAWT,6,system]
Wait for termination of Thread[AWT-XAWT,6,system]

I am on Linux Mint and Java 12.

Edit:
I commented //System.gc(); in line 445 and it threw this exception :

Found main ThreadGroup java.lang.ThreadGroup[name=system,maxpri=10]
Stop Thread[AWT-XAWT,6,system]
Exception in thread "AWT-XAWT" java.lang.IllegalMonitorStateException
Wait for termination of Thread[AWT-XAWT,6,]
Wait for termination of Thread[AWT-Shutdown,5,system]
	at java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:149)
	at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1302)
	at java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:439)
	at java.desktop/sun.awt.SunToolkit.awtUnlock(SunToolkit.java:203)
	at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:744)
	at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:652)
	at java.base/java.lang.Thread.run(Thread.java:835)
Wait for termination of Thread[AWT-EventQueue-0,6,main]

but this time GLFW window gets start but X Error of failed request: RenderBadPicture (invalid Picture parameter) apprears on closing the game.

oxplay2 · August 8, 2019, 7:07am

What if we have no settings dialog at all? I mean, as far as I understand, it’s a developer tool supposed to be hidden from end users on release versions of games, am I wrong?

Some of games had very similar pre-gl window settings.

So if your game crash, user can disable/change something to allow run application where will be even more settings(if need). For example resolution/fullscreen settings that user could change before.

Now imagine if you have settings only in game, when app/gl-window dont run, user can do nothing. (or try change some settings file at least)

As i know current can be changed to look as you need it, but predefined settings are what some of existing games use.

Ofc i understand anyway it can be done by developer if there will be no default pre-settings panel, but imo its fine if there is one.

RiccardoBlb · August 8, 2019, 7:42am

what java version are you using?

Ali_RS · August 8, 2019, 7:49am

…

RiccardoBlb · August 8, 2019, 8:03am

Ok, try to remove the code from line 466 to 483

github.com

riccardobl/jmonkeyengine/blob/0763be5bd22157637b8d8de012a19b9b46cffcdb/jme3-desktop/src/main/java/com/jme3/app/SettingsDialog.java#L466-L483


else if (t.getName().equals("AWT-XAWT")) {
    try {
        Class SunToolkit_c = getClass().getClassLoader().loadClass("sun.awt.SunToolkit");
        Method awtLock_m = SunToolkit_c.getDeclaredMethod("awtLock");
        Method awtUnlock_m = SunToolkit_c.getDeclaredMethod("awtUnlock");
        awtLock_m.invoke(null);
        try {
            t.stop();
            System.out.println("Stop " + t);
            waitForThreads.add(t);
        } catch (Exception e1) {
            e1.printStackTrace();
        }
        awtUnlock_m.invoke(null);
    } catch (Exception e2) {
        e2.printStackTrace();
    }                                
}

The_Leo · August 8, 2019, 8:04am

So, are you saying lwjgl3 does not work at all with eg Awt/Swing? If that’s the case it’s not only about a setting dialog, but also many user tools use jme3 along with plenty of swing dialogs.

Ali_RS · August 8, 2019, 8:05am

Going to try it soon.

Ali_RS · August 8, 2019, 8:12am

A solution would be to switch JME’s settings dialog from AWT to Eclipse SWT.

It seems to work smoothly with LWJGL3 and GLFW and there is already an example:

The SWT jar size for Linux is 2MB.

I just tried the demo and it works fine on my Linux:

and seems there is no problem on Mac OS.

Ali_RS · August 8, 2019, 8:42am

Okay, @RiccardoBlb I removed those lines and it works fine now.

It will be great if someone can test it on Mac.

pspeed · August 8, 2019, 9:30am

Again again again… it’s a real shame to suck in another giant GUI library JUST FOR A SETTINGS DIALOG.

Stupid, really.

Again again again again again again, the only choices are:

drop OSX support
drop the settings dialog
or my favorite: keep lwjgl2 until other things change

But you know… maybe instead of keeping lwjgl2 we could write a JavaFX wrapper around SWT around a JavaFX wrapper around SWT that calls OpenGL directly to wrap JavaFX and suck in X/Motif… and let’s throw in Win32 emulator while we’re at it… so we can offer a few settings for the user.

I mean, as un-user-friendly as JME normally is anyway, maybe command line options aren’t so bad after all.

Edit: or option (4), fix lwjgl3 for them, basically.

Ali_RS · August 8, 2019, 10:00am

I thought SWT with 2MB is considerably small in comparison with OpenJFX which is 44MB

But yeah, I agree adding another library just for Settings dialog is bad. I suggested this just in case we wanted to keep all the options. Supporting Mac while keeping Settings dialog and not adding JavaFX huge dependencies.

I agree that this is the best option at the moment.

Pauli · August 8, 2019, 1:33pm

In my humble opinion this should be the way to go, because it gives the most flexibility and does not couple a JME app so tightly with any settings dialog, GUI library, etc.

Devs could handle settings parameters in run configurations or something and provide end users either with a proper themed custom dialog or in-game options.

grizeldi · August 8, 2019, 5:29pm

I’ll second the command line params. It frees the developer to use whatever settings dialog he/she wants to use (if at all, not many modern games have them anymore, they just go straight into fullscreen). We would still need to come with the defaults when command line params aren’t present though. Fullscreen? 720p windowed? Something else?

The_Leo · August 8, 2019, 6:00pm

What are the actual benefits of Lwjgl 3 over 2?

From what I read so far, you can create multiple windows (lwjgl 2 cant), different input handling (is this advantage or disadvantage?), vsync?

drawbacks: awt issues.

Lwjgl 3 uses GLFW to create windows, and apparently, afaik, this is where the issue with awt is.

Lwjgl 2 uses Display class that creates a single window…

According to what I read the issues with Lwjgl 3 and GLFW are not so shallow as just don’t create gui with awt/swing and your’re okay. Apparently anything that gets the AWT thread started is an issue, eg. even something like using ImageIO.readImage… however there are workarounds
Source ( glfw causes program to hang · Issue #68 · LWJGL/lwjgl3 · GitHub )
They even link to another library for loading images…

Quote

If you want to use AWT with Mac OS X you need to set 
java.awt.headless to true by either calling 
System.setProperty("java.awt.headless", "true") 
or by using the -Djava.awt.headless=true JVM argument.

So is it safe to say AWT for lwjgl3 is an issue only for Mac OS X?

In my opinion, lwjgl-2 does the job fine, and lwjgl-3 is also there for anyone who’d like to try it.

fba · August 8, 2019, 6:11pm

I agree. I think that having or not a settings dialog should be a developer decision. That way, it is up to them to decide whether it is JavaFX, SWT or whatever, if any – even CLI.

pspeed · August 8, 2019, 6:28pm

Anecdotally, I’ve heard in chat rooms that lwjgl3 has problems with hardware cursors, slower performance on nvidia, full-screen-that-isn’t-really-full-screen on Linux, etc…

I’d hoped those folks would add to this thread about more specifics.

pspeed · August 8, 2019, 6:30pm

This is already true. Set the boolean to false then use whatever UI/options structure you want.

It’s for the default case that we’re talking about. A user trying to make a blue cube app for the first time shouldn’t have to worry about wiring up a UI just to try out different settings.

tonihele · August 9, 2019, 5:36am

Yeah, not being Linux nor JME savvy, I tend to blame myself about the issues first. We have been running our game with LWJGL 3 for maybe more than a year now. And I have seen some issues that I haven’t found reported upstream…That is the disclaimer for this unofficial list of LWJGL 3 oddities

Hardware cursor doesn’t work nicely when LWJGL 3 + Linux + NVIDIA proprietary drivers + cursor has alpha. The transparent areas on the cursor don’t redraw unless the cursor is moved (?). It does work with Intel driver on the same machine. So wut? NVIDIA driver bug on Linux? And we are the only people in the world using this feature anyway
The said NVIDIA combo provides less FPS versus LWJGL 2 setup, also on Windows! This however… I remember that it was reported on GLFW issues (NVIDIA label) but I didn’t find it. Could be that it is fixed also, I haven’t made the comparison recently. But I recon this can be verified or debunked by a lot of people on this forum alone

About the good things with LWJGL 3… For us, none? As already said in this thread, also LWJGL 2 has some issues running on some hardware, whereas LWJGL 3 seems to have less of those. If you translate the run to starting at all while counting out all the AWT stuff.

The multi monitor support LWJGL 3 brings is unused by JME or can’t be utilized through it if I got this right. I sense this would be a fairly easy thing to add. Monitor selection to the JME interfaces. This would at least provide some benefits over the LWJGL 2 and perhaps help the adoption.