Finish LWJGL 3 backend and request for testing

[badlogic]

LWJGL 3 backend

I just committed the first iteration of the new LWJGL 3 backend. Going forward, i hope this can largely replace the old LWJGL 2 backend, especially on Mac OS X where we have a lot of problems with LWJGL 2. The new backend is also prepared for multi-window environments, altough respective methods in Lwjgl3Application haven't been exposed yet.

The LWJGL 3 backend is structure the same way as the LWJGL 2 backend, including the main module in backends/gdx-backend-lwjgl3 and a test module in tests/gdx-tests-lwjgl3. Everything is wired up with Maven and Eclipse projects so you can test things. I also wired it up with our Ant build, haven't tested that one at all.

It would be amazing if you guys could help test this. I already build snapshots for the new backend, and all the code is merged with master. You can easily switch out the LWJGL 2 backend for the LWJGL 3 backend in Gradle. In your core projects dependencies, change:

compile "com.badlogicgames.gdx:gdx-backend-lwjgl:$gdxVersion"

to

compile "com.badlogicgames.gdx:gdx-backend-lwjgl3:$gdxVersion"

Make sure gdxVersion is set to the latest snapshot version 1.7.3-SNAPSHOT. In your desktop launcher, simply replace LwjglApplicationConfiguration and LwjglApplication with Lwjgl3ApplicationConfiguration and Lwjgl3Application. That's it.

Not implemented yet

• Window refresh callback for nicer resize
• HDPI support. Works out of the box on mac os x, but need to scale mouse coords accordingly. They are reported in logical coords, whereas Graphics reports framebuffer size now.
• Screen mode change related functions in Lwjgl3Graphics. Just haven't gotten around implementing those. Note that when changing the screen mode (e.g. window -> fullscreen), GLFW returns a new window handle. Lwjgl3Input and Lwjgl3Graphics need to re-register all the GLFW callbacks in that case with the new window handle.
• Clipboard support without AWT on Mac OS X
• Fix fullscreen toggling. On Mac OS X, the first windowed -> fullscreen switch fails in weird ways, e.g. clearColor has an effect, but rendering doesn't. Subsequent fullscreen -> fullscreen switches work as intended (but those use glfwSetWindowSize instead of creating a new window). On Window (10) fullscreen switching doesn't work at all on HDPI monitors, need to test on normal monitors. Bug for Windows, Bug for Mac OS X. Should be resolved in GLFW, libGDX side does the proper thing.
• Custom cursors in Lwjgl3Graphics. Haven't checked how to do that yet.
• Application icon support. This needs to be covered via tools like PackR
• Platform-specific multi-window API (Lwjgl3Application#newWindow(ApplicationListener, int width, int height)/newWindow(ApplicationListener, DisplayMode)).
• Controller support. GLFW comes with its own controller API, should be simply to add that to the controllers extension. There's a bug on Windows in GLFW, where all gamepads are reported by the same name. This makes mapping controller types impossible.
• OpenGL 3.0 support. We should only need to add that to Lwjgl3Application#createGlfwWindow. The Lwjgl3GL30 implementation is prepared, except for Lwjgl3GL30#glGetBufferPointerv
• Mac OS X (potentially Windows and Linux too): glfwSwapBuffers doesn't block in windowed mode if app window is fully behind other window or minimized. Bug with GLFW. Could "fix" it in our own code.
• Lwjgl3Input#getTextInput(), can't call into Swing/AWT
• Non-continuous rendering in Lwjgl3Graphics. It's a bit of a bitch. Lwjgl3Input will already call Graphics#requestRendering() in case new input events arrive
• Make OpenALAudio thread-safe, put the update on a separate thread

Known Issues

• LWJGL 3 is based on GLFW. GLFW and AWT don't play nice with each other. Calling Swing/AWT stuff is thus not possible at the moment.
• On Mac OS X, you need to pass the JVM argument -XstartOnFirstThread when starting your app. We may be able to fix both things to some extend.
• If you use the multi-window API, understand that any Runnable you post via Gdx.app.postRunnable() may be executed in such a way that the statics in Gdx, like Gdx.graphics may point to a window other than the one for which the runnable was posted.

[intrigus]

We should ensure that this bug is fixed or we should try to fix it.
glfw/glfw#608

[badlogic]

We can fix that on our end by checking if the reported position has changed since the last time.

[piotr-j]

I've had a go at it, besides documented things:

• no fps options in config
• resize never gets called, related to screen mode stuff probably
• no way to get Display.getPixelScaleFactor() ie if hdmi is in effect

Seems to be working fine on Win10

[badlogic]

Resize isn't supposed to get called on startup. Does it get called when you resize the window?

The fps options in config are a very bad idea imo. It's either vsync or not. Limiting fps by sleeping the main thread is a terrible thing and results in jank.

I can see what i can do about exposing whether you are running in HDPI mode or not.

[badlogic]

Regarding HDPI: we actually now report the real resolution of the framebuffer instead of the logical resolution via Gdx.graphics.getWidth()/getHeight(). A specific flag that says "This is 2x retina" doesn't make a lot of sense imo. You have to accomodate a lot of different screen sizes anyways, which will just work for the 2x retina case as well.

[intrigus]

Does Clipboard work? It shouldn't work on mac, because it uses AWT.

Will PRs that implement missing features be merged or will you implement the features anyway?

[piotr-j]

After some more investigation, resize is called for each frame while window is being resized. Viewports dont like this for whatever reason and stuff is all kinds of broken.
Yeah sleeping to reduce fps is jank, but some way to throttle would be nice if possible.
If real resolution is reported, a flag is not needed indeed.

[Darkyenus]

Regarding HDPI: we actually now report the real resolution of the framebuffer instead of the logical resolution via Gdx.graphics.getWidth()/getHeight(). A specific flag that says "This is 2x retina" doesn't make a lot of sense imo. You have to accomodate a lot of different screen sizes anyways, which will just work for the 2x retina case as well.

Please reconsider, I'd very much like to know in my app whether the hi-dpi mode is active and if it is - what the pixel/point ratio is (to use Apple terminology). For example, I have a 100% UI app. With lwjgl2 backend I launch it on my retina primary monitor and set up the viewport to be in "points", not in pixels (I just divide it by two for now), because otherwise, all UI would be ridiculously small. This works and everything is crisp. But when I drag the window to my secondary, non-retina, monitor, everything is huge, because I can't tell whether or not is the hi-dpi mode active. Graphics already has some Ppi and Density methods, but these don't help much in this case. Something like getLogicalPixelScale() (with less terrible name), which would return 1f on non-retina, 2f on retina, etc. would be very useful and appreciated.

But I may have misunderstood or overlooked something.

[billy1380]

I am testing on Linux; getting this exception:

LwjglApplication: Couldn't initialize audio, disabling audio
java.lang.NoSuchMethodError: org.lwjgl.openal.AL.create()V
    at com.badlogic.gdx.backends.lwjgl.audio.OpenALAudio.<init>(OpenALAudio.java:72)
    at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:85)
    at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:66)
    at xxxxxxxx.desktop.DesktopLauncher.main(DesktopLauncher.java:38)
Exception in thread "main" java.lang.ExceptionInInitializerError
    at com.badlogic.gdx.backends.lwjgl.LwjglInput.<init>(LwjglInput.java:93)
    at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:93)
    at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:66)
    at xxxxxxxx.desktop.DesktopLauncher.main(DesktopLauncher.java:38)
Caused by: java.lang.SecurityException: sealing violation: package org.lwjgl is sealed
    at java.net.URLClassLoader.getAndVerifyPackage(URLClassLoader.java:388)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:417)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at org.lwjgl.input.Keyboard.<clinit>(Keyboard.java:265)
    ... 4 more

not getting as far as rendering :(

[Osaris31]

billy1380, that's likely because you didn't replace LwjglApplicationConfiguration and LwjglApplication with Lwjgl3ApplicationConfiguration and Lwjgl3Application everywhere in your desktop launcher.

[billy1380]

Thanks @Osaris31

[Osaris31]

Nice work @badlogic ;) I tested in my game (I edited Lwjgl3Graphics to add OpenGL3).
It works pretty well, no FPS change from the previous backend, no crash.
A couple issues: my InputAdapter doesn't seem to receive mouseMoved anymore, as well as a few keys (Tab, /, ...), but for exemple WASD and touchDown are still received.

[billy1380]

Works very nicely... seems to have sorted #3527 too!

[mbrlabs]

@Osaris31 i can confirm this (on Linux). The middle button of the mouse is also not working...but polling via Gdx.input.isButtonPressed works fine.

Everything else works great so far.

[badlogic]

Awesome feedback everyone. I'll try tl stabilize it over the next few days! Please keep the feedback coming. I'll think about a solution for HDPI reporting as well.

[badlogic]

Oh, and if you report further issues, please always state what OS you are on!

[badlogic]

@mbrlabs what flavor of Linux are you on using which window manager?

[badlogic]

@Osaris31 what operating system and version? Fullscreen or windowed?

[Osaris31]

@badlogic Win10, windowed

[badlogic]

@Darkyenus here's how i fixed HDPI support. Pending minor changes.

1. Added Graphics#getBackBufferWidthand Graphics#getBackBufferHeight. These report the physical dimension in pixels of the back buffer we render to in OpenGL. These are the sizes you need to use with glViewport and glScissor, as they expect back buffer coordinates. I added a class called HdpiUtils that you can use to keep working in logical coordinates, even when calling glViewport and glScissor.
2. Graphics#getWidth and Graphics#getHeight as well as all mouse coordinates are always reported in logical screen coordinates, just like the operating system would report them to you. You can check if you are in HDPI mode by comparing the logical width/height to the back buffer width/height.
3. ScissorStack and viewports of stage2d have been modified to use HdpiUtils instead of directly calling glViewport and glScissor. Your scenario of dragging a window from a HDPI to a normal DPI monitor and back now works flawlessly without any manual scaling or orther stupid stuff.
4. If you dislike the impedance mismatch between logical and back buffer coordinates, you can enable HDPI reporting via Lwjgl3ApplicationConfiguration#useHDPI. Everything will then be reported in back buffer coordinates, e.g. Graphics#getWidth() and mouse coords, no logical coordinates to be found.

[intrigus]

LwjglGraphics.GetWidth() doesn't return the logical size (as stated in the javadocs), it returns the frame buffer size, or did I miss something?

[mbrlabs]

@badlogic Arch Linux with Cinnamon and windowed

[mbrlabs]

@badlogic alright, i guess i figured it out. I am using the touchDragged of the InputProcessor. I tought it's not called because my camera was not moving (but actually it is). It's simply that screenX and screenY are always 0. In the update method of the Lwjgl3Input you are setting the delta values always to zero. Is that intened? Because if i remove these two lines, it works again

[mbrlabs]

@badlogic it's actually just Gdx.input.getDeltaX() and Gdx.input.getDeltaY() which are not working correctly...screenX and screenY of the InputProcessor callbacks are fine

[Darkyenus]

@badlogic Perfect thanks! So now the "hi-dpi" mode is active by default? i.e. with default settings, when running on retina display, getWidth and getBackBufferWidth will differ? That might break some applications as this behavior (or what we have now) is opt-in in in lwjgl2 backend. Also, the useHDPI for using "most pixels available" is IMO a bit misleading name, because it is not really hi-dpi anymore, it is just making things "small".

What about solving both of these problems with enum setting:

enum HDPIModes {
    NO_HDPI, //Current default lwjgl2 behavior, default and simple, UI is never small, but not crisp on retina
    HDPI, //Your solution, getWidth differs from getBackBufferWidth on retina, for apps that know how to handle it
    FORCE_HDPI; //(or better name), similar to HDPI but getWidth always returns getBackBufferWidth. I am not sure what would it be good for, but somebody will probably find a good use.
}

That way, with NO_HDPI as default, non retina-aware games won't break down when launched on retina display, but others can still use it. Maybe I am overthinking it though.

[badlogic]

@mbrlabs thanks for figuring it out. DeltaX/Y should work, i'll look into it!

@Darkyenus i think we need to educate users on HDPI. As such, i prefer the correct way of doing it, that is separate logical resolution from physical resolution, which is option 2 in your enum. GLFW introduced this, and i think it's a good way to go about things. The not crispyness of option 1 needs to die. And again, the only thing people need to watch out for in option 2 is glViewport, glScissor and glReadPixels. Something pretty much no libGDX user uses manually anyways. Any usage inside of the core libs will be Hdpi aware.

[badlogic]

@mbrlabs thanks for reporting, this is fixed now (together with other polling methods).

[mbrlabs]

great! i will keep an eye on this backend.
The multi-window support looks very interesting.

[Darkyenus]

@badlogic Ok, that will lead to (hopefully) better applications, but has steeper learning curve. In that case, do we need the useHDPI flag at all? Hi-DPI is always enabled, so the name is a bit confusing and I am not sure if it is worth having, same effect can be achieved by just calling different methods, so it only adds internal complexity for no real benefit. At least I can't see any use case.

[FortressBuilder]

• In Lwjgl3Application#loop: It is probably better to reuse the closedWindows array instead of creating it inside the loop every frame.
• The callbacks should be release()d once they are not used any more and GLFW should be glfwTerminate()d. You can run the program with -Dorg.lwjgl.util.DebugAllocator=true to have the location of memory leaks reported.
• In Lwjgl3Application#createGlfwWindow: Instead of parsing the GL_VERSION and using glfwExtensionSupported you can use the GLCapabilities instance returned by GL.createCapabilities() to check for supported versions or extensions.
• In Lwjgl3Application#initializeGlfw: You create a glfw error callback but don't ever set it with glfwSetErrorCallback. This should be done before glfwInit so initialization errors are reported as well.

[piotr-j]

@cypherdare @kotcrab setting the window size limits to non default values fixes the problem. Perhaps it helps on windows as well? Looks like its a bug in GLFW.

[kotcrab]

@piotr-j config.setWindowSizeLimits(0, 0, 9999, 9999) doesn't help on Windows.

[cypherdare]

@piotr-j @kotrab I think we might be talking about two different issues. One where an unnecessary resize(0, 0) call is made when minimizing in Windows, and one where the window is actually physically resized to 0, 0 when manually resizing a window on OSX. The second issue is the one where config.setWindowSizeLimits(0, 0, 9999, 9999) seems to help.

[CreamyCookie]

@badlogic I've found 2 small issues:

1. Lwjgl3ApplicationConfiguration has no addIcon function.

2. When I start Hiero (from GDX-tools) I get this (it works with LWJGL 2):

Exception in thread "AWT-EventQueue-0" java.lang.SecurityException: sealing violation: package org.lwjgl.opengl is sealed
    at java.net.URLClassLoader.getAndVerifyPackage(URLClassLoader.java:399)
    at java.net.URLClassLoader.definePackageInternal(URLClassLoader.java:419)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:451)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.setVSync(LwjglGraphics.java:557)
    at com.badlogic.gdx.backends.lwjgl.LwjglCanvas.initialize(LwjglCanvas.java:123)
    at com.badlogic.gdx.backends.lwjgl.LwjglCanvas.<init>(LwjglCanvas.java:68)
    at com.badlogic.gdx.tools.hiero.Hiero.<init>(Hiero.java:182)
    at com.badlogic.gdx.tools.hiero.Hiero$21.run(Hiero.java:1579)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:709)
    at java.awt.EventQueue$3.run(EventQueue.java:703)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

---

I'm using gdxVersion = '1.9.4-SNAPSHOT' on Ubuntu 16.04
Java is /usr/lib/jvm/java-8-openjdk-amd64/bin/java

btw. Thanks for your work! 👍

[xGnoSiSx]

I may be a total ass for reporting this here, but I just tried the gdx-tests-lwjgl3 starter app on a new libgdx cloned repo (latest & greatest version) and got the below. Are these not changed or implemented just yet?

[LWJGL] GLFW_INVALID_VALUE error
Description : Invalid window size limits
Stacktrace :
org.lwjgl.glfw.GLFW.glfwSetWindowSizeLimits(GLFW.java:1968)
com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createGlfwWindow(Lwjgl3Application.java:415)
com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createWindow(Lwjgl3Application.java:366)
com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.(Lwjgl3Application.java:107)
com.badlogic.gdx.tests.lwjgl3.Lwjgl3TestStarter.main(Lwjgl3TestStarter.java:45)

[cypherdare]

@xGnoSiSx Try setting applicationConfig.setWindowSizeLimits(0, 0, 9999, 9999);.

There is a GLFW bug (fixed here) that has not trickled down to an LWJGL release yet.

[magicgoose]

regarding useHDPI:

How do I get real screen density? The Gdx.app.graphics.density is the same value regardless of useHDPI value.

Also, contrary to #3673 (comment), I get doubled pixels when useHDPI is false. (running on a rMBP with OS X 10.11.6)

I'm testing it with libgdx 1.9.5-SNAPSHOT

[ghost]

There is a bug with controller support. It doesn't exist(I think)

Exception in thread "main" com.badlogic.gdx.utils.GdxRuntimeException: Error creating controller manager: com.badlogic.gdx.controllers.lwjgl3.Lwjgl3ControllerManager
	at com.badlogic.gdx.controllers.Controllers.initialize(Controllers.java:105)
	at com.badlogic.gdx.controllers.Controllers.addListener(Controllers.java:52)
	at com.qookie.ludumdare.LDMain.create(LDMain.java:74)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.initializeListener(Lwjgl3Window.java:275)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.update(Lwjgl3Window.java:242)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.loop(Lwjgl3Application.java:138)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:107)
	at com.qookie.ludumdare.desktop.DesktopLauncher.main(DesktopLauncher.java:13)
Caused by: com.badlogic.gdx.utils.reflect.ReflectionException: Class not found: com.badlogic.gdx.controllers.lwjgl3.Lwjgl3ControllerManager
	at com.badlogic.gdx.utils.reflect.ClassReflection.forName(ClassReflection.java:30)
	at com.badlogic.gdx.controllers.Controllers.initialize(Controllers.java:102)
	... 7 more
Caused by: java.lang.ClassNotFoundException: com.badlogic.gdx.controllers.lwjgl3.Lwjgl3ControllerManager
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)
	at com.badlogic.gdx.utils.reflect.ClassReflection.forName(ClassReflection.java:28)
	... 8 more

[BSVogler]

@badlogic: I understand your argumentation on the limitFPS/vsync but I think you miss something. What if I don't want to enable v-sync because of the one-frame lag but still don't want my CPU or GPU to run at 100%? There is no need for 300 FPS on a 60 HZ monitor. As far as I can see this is currently not possible with the new API.

[thekeenant]

There seems to be really bad input lag for text fields with the lwjgl3 backend only when vsync is enabled. I created a small test and it demonstrates the issue on my machine (ubuntu 16.04). The key typed callback is really slow - key up and down are normal. Also, the lwjgl backend is fine, just lwjgl3.

• video demo: the output to the screen is just tied to an input processor, you can see how the key typed one lags behind the others if you type fast. Once I disable vsync it is fixed.
• source

[Darkyenus]

@thekeenant That looks pretty severe. Does this still happen when you turn off vsync but "simulate it" by putting Thread.sleep(1000/60) (or more) into render()?

[thekeenant]

@Darkyenus I get the same effect with vsync off and Thread.sleep(1000/60) . Hard to say if the effect is compounded with both vsync on and thread sleep on. updated this gist

Edit: Can't reproduce on Windows 10 with the same hardware.

[Darkyenus]

I can't reproduce it on OSX 10.11.6, even with high sleep times, so this is probably not libGDX but GLFW related. The closest thing I found on their issue tracker to this is this issue, but I'm not sure if it is the same problem.

[thekeenant]

@Darkyenus Yeah I noticed that after I posted and it definitely looks related... Might try plain GLFW and see what happens. For now I can stick with good old lwjgl - thanks for the help!

[jpauty]

I've opened the following PR #5443 . This is a fix for mouses with "continuous" wheels or osx touch pads. These devices can report scroll events that are lower than one. They also support acceleration and report scroll events greater than one. Without the PR the scroll is ultra fast, because small movements (e.g. a scroll of 0.1) are rounded up to scroll events of 1 unit.

This only fixes vertical scrolling. Horizontal could be better propagated from lwjgl to libgdx, but this would require some API changes.

Could anybody review this PR ?

[egordorichev]

I can report that running default template project (generated without any extensions or other things) on macos with this backend causes crash:

java.lang.ExceptionInInitializerError
  at org.lwjgl.glfw.GLFW.glfwCreateWindow(GLFW.java:1647)
  at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createGlfwWindow(Lwjgl3Application.java:442)
  at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createWindow(Lwjgl3Application.java:391)
  at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createWindow(Lwjgl3Application.java:379)
  at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:108)
  at org.rexcellentgames.burningknight.desktop.DesktopLauncher.main(DesktopLauncher.java:134)
Caused by: java.lang.IllegalStateException: GLFW windows may only be created on the main thread and that thread must be the first thread in the process. Please run the JVM with -XstartOnFirstThread. For offscreen rendering, make sure another window toolkit (e.g. AWT or JavaFX) is initialized before GLFW.

Tried running with -XstartOnFirstThread, getting the same result. Tried every possible fix found on web - no result.

[code-disaster]

Tried running with -XstartOnFirstThread, getting the same result. Tried every possible fix found on web - no result.

I've never seen this fail. Make sure you set this as a VM parameter, not as a command line argument.

[egordorichev]

@code-disaster I'm not sure what in lwjgl3 backend causes it, but anyway, I tried every single possible way to fix it suggested online and dug up the source, yet did not find a fix. Had to roll my huge codebase back to lwjgl2 backed to get mac support working. It's not too bad, but I really miss some features :x

[electronstudio]

@egordorichev If you are adding -XstartOnFirstThread to the launch options in IntelliJ it does not work. You have to add it to the run task.

task run(dependsOn: classes, type: JavaExec) {
    main = project.mainClassName
    classpath = sourceSets.main.runtimeClasspath
    standardInput = System.in
    workingDir = project.assetsDir
    ignoreExitValue = true
    jvmArgs '-XstartOnFirstThread'
}

[ikyatov]

From "Not implemented yet":
"Mac OS X (potentially Windows and Linux too): glfwSwapBuffers doesn't block in windowed mode if app window is fully behind other window or minimized. Bug with GLFW. Could "fix" it in our own code."
glfw/glfw#680 closed, its mean that gdx-backend-lwjgl3 was fixed?

[crykn]

As the issue was closed as part of glfw 3.3 and lwjgl 3.2.1 is using it, this should be fixed (at least in 1.9.10+).

[noblemaster]

Given this appears to be completed, I'll close this. We can re-open as needed or create a new issue/PR later. Thanks everyone for the hard work & comments :)