jMonkeyEngine / jMonkeyEngine/jmonkeyengine
GLFW Main Thread Issues
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 4.3k
- Forks
- 1.2k
- Avg merge
- 4d 7h
- Merged PRs (30d)
- 14
Description
So, we have a few issues open around that but they mostly address symptoms of lwjgl3's problems, where they are at it's core design decisions of GLFW that we have to address hereby.
So, the problems are: https://github.com/LWJGL/lwjgl3/issues/311 and "the OS only delivers key input events to the Main Thread anyway".
This concept is orthogonal to lwjgl2s/Applications start() method, which is expected to return either directly or after the context is created, but certainly it should NOT "join" the Render Thread.
This can all be worked around by making GLFW init on the main thread and then spawn a render thread, which can use glfwMakeCurrent (or comparable) to bind the openGL Context to the Render Thread and not the GLFW Main Thread.
That approach has two possible problems:
- When we return from start(), the Main Thread will end at some point. Would Key Events still arrive? Would the window close?
- Is there GLFW API (Resize Window, Recreate Window) which is then impossible to do?
If we can't fix these problems, the only thing we can do is annotate start() with the information, that this will never return until the application has been terminated.
Note that the following files use the glfw api and thus potentially require the MainThread. This can be seen in the docs, see https://www.glfw.org/docs/latest/group__input.html#ga1caf18159767e761185e49a3be019f8d
./src/main/java/com/jme3/input/lwjgl/GlfwJoystickInput.java
./src/main/java/com/jme3/input/lwjgl/GlfwMouseInput.java
./src/main/java/com/jme3/input/lwjgl/GlfwKeyInput.java
./src/main/java/com/jme3/input/lwjgl/GlfwKeyMap.java
./src/main/java/com/jme3/system/lwjgl/LwjglWindow.java
./src/main/java/com/jme3/system/lwjgl/LwjglContext.java
It has to be checked whether all of this code can be run before kicking off rendering, then we'd cover 90% already. Then we can only fall to the above two problems.
As far as I know LWJGL3s approach was to decouple GL from Window Management, though, so in case we cannot fix this, we will have to use another window manager, which should be doable as well.
Is someone curious enough to look into these files?
Edit: How about splitting LwjglWindow's run() method so that we do "initInThread" really in thread and only the runLoop in the Thread then? I am not sure if that is sufficient, but it looks like all init is properly done in initInThread.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading LwjglWindow.java and LwjglContext.java, then inspect the GLFW calls in GlfwJoystickInput.java, GlfwMouseInput.java, GlfwKeyInput.java, and GlfwKeyMap.java alongside the linked GLFW input documentation. Determine whether initialization can occur before rendering and whether events, window operations, and start() behavior remain valid when rendering uses a separate thread; done means these constraints are resolved or the required limitation is documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- desktop, game-dev
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100