jme3test.app.TestApplication hangs with LWJGL3

[stephengold]

Current master branch running on Windows:

• With LWJGL2, TestApplication completes in < 20 seconds without user input, after displaying a black window and a black fullscreen.
• With LWJGL3, TestApplication displays the black window, then waits for the user to close the window. If the user closes the window, it pauses, displays the black fullscreen, and hangs. ALT-Tab is required to regain control.

[stephengold]

Observed similar behaviour on Linux.

[louhy]

I get the same result here on Linux. Curiosity struck so here's an analysis.

TLDR: It seems to me the test is incompatible with the way the LWJGL3 context class works (LwjglWindow.java). LWJGL2 creates a separate thread for rendering loop, 3 uses the current
(test!) thread for the rendering loop - so obviously, it blocks.

That's probably all that's needed, but here's my original verbose version:

This test expects the current thread to be allowed to continue after calling start() (which eventually calls context.create()). That's fine for LWJGL2, which looks like this (see: LwjglDisplay.java):

    public void create(boolean waitFor){
        if (created.get()){
            logger.warning("create() called when display is already created!");
            return;
        }
        new Thread(this, THREAD_NAME).start();
        if (waitFor)
            waitFor(true);
    }

But with LWJGL3 this is what it does (see: LwjglWindow.java):

    public void create(boolean waitFor) {
        if (created.get()) {
            LOGGER.warning("create() called when display is already created!");
            return;
        }
        // NOTE: this is required for Mac OS X!
        mainThread = Thread.currentThread();
        run();
    }

That run() never lets the current thread continue on (rendering loop), so the test gets stuck. Closing the window I guess kills the context or something, and apparently breaks it out of the loop in run(). Fullscreen there's no window to close, so it gets "stuck".

So I think due to the way the context classes work, I would say this test is just fundamentally incompatible with LWJGL3.

If the test can be made specific to an LWJGL version, I would say this should be a test for 2 only.

[louhy]

Just to see what happens I tried having the LWJGL3 class create a new thread like 2 does, it passes the test and seems to work fine (Linux).

I see the "required for Mac" comment... wouldn't be hard to do an OS-specific if so that it behaves the same with other OSes. But just to make the test pass, I'm going to assume that's not worth doing.

But I guess that Mac hack is really why the test fails.

[MeFisto94]

This is a manifestation of yet another problem with LWJGL3. You even need some weird jvm launch argument for mac os, so I guess even with that hack the test would fail.
@riccardobl had an approach at fixing this, it was also related to the settings dialog and all weird hacks, so we should maybe fix this all for once.

[MeFisto94]

Found something riccardobl@0763be5
We should set up a dedicated issue and work on lwjgl3 somehow to finally make it good. The attached milestone is only a part of all problems.

[stephengold]

Transitioning the Engine to LWJGL3 should be one of the goals of the 3.3.0 release.

I'm not convinced LWJGL3 needs its own milestone; perhaps a GitHub label would make more sense. A GitHub issue or pull request can only have at most one milestone, but it can have many labels.

[louhy]

Yeah there's definitely some work before v3 compatibility is on par wth v2. That settings dialog patch may work fine for pre-Java 9 but I have strong doubts it'd be future proof, since it uses stuff like sun.awt.SunToolkit, all that Sun stuff is supposed to be private API. ☹️

It's a shame there doesn't seem to be much interest in introducing a JavaFX dependency and dropping Swing, it might be a fun mini-project to rebuild the whole dialog with JFX, and try to knock that kind of issue out at the same time.

Edit: Just in case it matters at some point, just realized there's also LwjglWindowVR.java which also will hijack the test thread like LWJGL3 does.

[tlf30]

I believe this is related to #1048

[stephengold]

Just confirmed that the issue is still present in v3.4.0-beta4.

[stephengold]

I verified the fix on Windows 10 and on Linux, with LWJGL 3.3.0, both from the test chooser and executing TestApplication as a standalone app. The only weirdness was on Linux with the test chooser:

Dec 08, 2021 2:18:28 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
INFO: Audio effect extension version: 1.0
Dec 08, 2021 2:18:28 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
INFO: Audio max auxiliary sends: 2
Destroying offscreen buffer
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  20 (X_GetProperty)
  Resource id in failed request:  0x4c00007
  Serial number of failed request:  1598
  Current serial number in output stream:  1598