Skip to content

Conversation

@stephengold
Copy link
Member

This a step toward allowing JME applications developed for Linux/Windows to run on macOS without any changes. Since LWJGL v2, doesn't support the newer "Apple Silicon" hardware, the focus is on LWJGL v3. For portability, we want to use the "glfw_async" library (added in LWJGL v3.3.1) when running on macOS. To reduce the risk of regressions, we'll use the old library when running on other operating systems.

For extra flexibility, a new AppSetting named "GlfwLibraryName" specifies which library to use: "glfw" or "glfw_async". If this setting is unset or null, org.lwjgl.system.Platform is used to determine which library to use.

@stephengold stephengold added this to the Future Release milestone Mar 4, 2022
@riccardobl
Copy link
Member

riccardobl commented Mar 4, 2022

I think it would be better to set Configuration.GLFW_LIBRARY_NAME only if the libraryName != null or platform == MACOS, so that the default becomes whatever LWJGL3 think the default is (except on macos).

@stephengold
Copy link
Member Author

I'm converting this to a draft PR both because of the suggestion from @riccardobl and also because I'm unsure the best place to set "glfw_async".

@stephengold stephengold marked this pull request as draft March 25, 2022 00:50
@stephengold
Copy link
Member Author

This PR is still on hold because I've been investigating issues with "glfw_async". I'm convinced it's unreliable in LWJGL v3.3.1, causing certain apps to crash (in a highly reproducible fashion) with "BUG IN CLIENT OF LIBDISPATCH: dispatch_sync called on queue already owned by current thread". The same apps work OK with ordinary "glfw" and -XstartOnFirstThread. When I have time, I hope to create a compact test case to send to the LWJGL and/or GLFW folks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants