Could change the String check to something like this.
if (Platform.get() == Platform.MACOSX ) {
..... Then start it how mac needs.
}
This check is part of LWJGL3.2 , this removed the string checking.
Also could add the following method to check if it mac and not 1st thread to through an exception instead of hanging.
We could do something like this for checking to prevent the crash
/*
* Copyright LWJGL. All rights reserved.
* License terms: https://www.lwjgl.org/license
*/
package org.lwjgl.glfw;
import org.lwjgl.system.*;
import org.lwjgl.system.macosx.*;
import static org.lwjgl.system.APIUtil.*;
import static org.lwjgl.system.JNI.*;
import static org.lwjgl.system.MemoryUtil.*;
import static org.lwjgl.system.macosx.LibC.*;
import static org.lwjgl.system.macosx.ObjCRuntime.*;
/**
* Contains checks for the event loop issues on OS X.
*
* <p>On-screen GLFW windows can only be used in the main thread and only if that thread is the first thread in the process. This requires running the JVM with
* {@code -XstartOnFirstThread}, which means that other window toolkits (AWT/Swing, JavaFX, etc.) cannot be used at the same time.</p>
*
* <p>Another window toolkit <em>can</em> be used if GLFW windows are never shown (created with {@link GLFW#GLFW_VISIBLE GLFW_VISIBLE} equal to
* {@link GLFW#GLFW_FALSE GLFW_FALSE}) and only used as contexts for offscreen rendering. This is possible if the window toolkit has initialized and created
* the shared application (NSApp) before a GLFW window is created.</p>
*/
final class EventLoop {
static final class OffScreen {
static {
if (Platform.get() == Platform.MACOSX && !isMainThread()) {
// The only way to avoid a crash is if the shared application (NSApp) has been created by something else
SharedLibrary AppKit = MacOSXLibrary.getWithIdentifier("com.apple.AppKit");
try {
long NSApp = AppKit.getFunctionAddress("NSApp"); // The NSApp global variable is an exported symbol
if (memGetAddress(NSApp) == NULL) {
throw new IllegalStateException(
isJavaStartedOnFirstThread()
? "GLFW windows may only be created on the main thread."
: "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."
);
}
apiLog("GLFW can only be used for offscreen rendering.");
} finally {
AppKit.free();
}
}
}
private OffScreen() {
}
static void check() {
// intentionally empty to trigger the static initializer
}
}
static final class OnScreen {
static {
if (Platform.get() == Platform.MACOSX && !isMainThread()) {
throw new IllegalStateException(
"Please run the JVM with -XstartOnFirstThread and make sure a window toolkit other than GLFW (e.g. AWT or JavaFX) is not initialized."
);
}
}
private OnScreen() {
}
static void check() {
// intentionally empty to trigger the static initializer
}
}
private EventLoop() {
}
private static boolean isMainThread() {
if (!Configuration.GLFW_CHECK_THREAD0.get(true)) {
return true;
}
long objc_msgSend = ObjCRuntime.getLibrary().getFunctionAddress("objc_msgSend");
long NSThread = objc_getClass("NSThread");
long currentThread = invokePPP(NSThread, sel_getUid("currentThread"), objc_msgSend);
return invokePPZ(currentThread, sel_getUid("isMainThread"), objc_msgSend);
}
private static boolean isJavaStartedOnFirstThread() {
return "1".equals(System.getenv().get("JAVA_STARTED_ON_FIRST_THREAD_" + getpid()));
}
}
This way we can remove the string check and let LWJGL tell you the machine type. Basically there are only three types of machines, Windows, Mac and Linux. Of course there are tons of types of Linux but at the end of the day they are Linux.
Portability across platforms should be an Engine responsibility, not something app developers should have to worry about.
I believe we all want to move forward into an LWJGL v3-only world. However, there are many different paths we can take toward that goal, and that’s where conflict arises.
Given the difficulty of finding someone to test JME on macOS, I’d consider ending support for it … if that would help us move forward.
I would have to agree. I know there is a tiny user base using jme3 on macos. But considering the difficulty for us to work on macos support without having a mac. I would say that we should either drop support, or if someone with a macos device would like to take up supporting macos, then that would be fine.
This scenario where people without Macs are attempting to maintain MacOS specific code for MacOS support is not working.
If no one in the community comes forward to maintain the MacOS support (who has a mac and can test), then my two cents is to drop support for it.
Edit: I would like to note, the last time I saw any of my jme3 apps running on a modern mac, the opengl support was so bad that most of the shaders produced unexpected results.
On the other hand, some years ago Normen was full-on addicted to Mythruna and could be found logged into my Mythruna server at all hours of the day… and he’s a well known Mac-only user (at least back then).
So it used to work quite well. Just unfortunate that Apple gets more developer hostile every day.
And just to say, the 3.5 release will actually have some Mac fixes. Retina specific setting and HiDPI stuff that are more common on Mac than anywhere else. Those were indeed tested with Mac.
A combination of timing and that It’s more difficult to test lwjgl3 on osx due to the example/launcher and settings screen. It looks like lwjgl3-awt has added support for osx but I haven’t had a chance to test it yet.
This PR is low-risk because it concerns only a log in a single class, and it is (IMHO) high-value because it concerns the performances of a method in the critical path (i.e. something that must be done in the main thread during the update()). Although the perf impact may seem low, it was sufficiently high to be spotted during my investigations.
I agree it’s a good change and worthy of a point release.
Note: if you find detach to be a measurable “bottleneck” then there are lots of reasons not to detach so many things in a single frame.
It’s still a good change, though… because the old code is silly and from experience silly code is 100x more likely to be emulated/copypasta’d elsewhere.
@pspeed : Actually I am not detaching many nodes (just 2 or 3 in the update), so it isn’t strictly speaking a bottleneck.
My objective is to run my game on low-end Android devices at the fastest frame rate (i.e. trying to reach 60 fps…) and, even more importantly, avoid noticeable lags.
I’m thus hunting all performances issues on the critical path, and such hardware has the benefit to reveal anything suboptimal .
During my investigations, I noticed a (slight) lag when updating the node hierarchy and went to this PR.
This lag of course can’t be revealed with regular GPU hardware.
I think we’re nearly done with PR 1665. Perhaps I can help complete it. With your permission, I’d like to push (not force-push) commits directly to the “colorAdjustmentFilter” branch of your “BranchedJme3” repo. Would that be OK?
You are authorized to do this, I have no problem at all, but I have no time to review any changes, so consider someone else to review the changes (if you plan to merge directly after applying the requested changes, otherwise I will be available in 2 more weeks for reviewing code and PRs).
Good luck and let us know how it goes !
EDIT : I have invited you to gain a full access on this repo and push on the branch ‘colorAdjustmentFilter’ directly, I think that would directly add commits to my PR :
After you’ve created a pull request at GitHub, there’s often a checkbox in the “Discussion” tab (at the bottom of the right sidebar), which you can use to give maintainers edit permission. Since I’m a maintainer, that would’ve been sufficient in this case.
.