Finish LWJGL 3 backend and request for testing

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.

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

[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