MacOS support overhaul, Apple M1 and breaking changes

Development
1

Last week i started working to improve our mac os support, the progress is tracked on this Project on github:

Most notable changes are:

- Testing Apple Silicon M1 support

- Fix issues regarding HiDPI and scaling #1750

Separate the concept of resolution from window size. Since they do not match in mac os (and possibly other platforms aswell) when using high dpi resolution.

- OpenGL 3.2 used by default #1752

This enforces a more recent core profile, since the compatibility profile seems to be broken in mac os (see related issue for more info).

- ErrorDialog and SettingsDialog removed from the internal code #1748

These two dialogs use AWT that is known to not work when GLFW is started on the same thread, and this is a requirement for MacOS, see issue here.

So I’ve decided to remove SettingsDialog from the internal code and re-propose it as a standalone class, so that devs that still like it can use it, without keeping broken code enabled by default that might discourage new devs.

After this PR is merged, the awt SettingsDialog can be shown as follow:

AppSettings settings=new AppSettings(true);
if(SettingsDialog.showDialog(settings)){
  app.setSettings(settings);
  app.start();
}

this will recreated the current behavior.

I’ve also removed the ErrorDialog that is source of some issues with mac (but also other platforms, see issue for more info). The error dialog is replaced with an error handler callback, usable as follow:

JmeSystem.setErrorMessageHandler((message)->{

});

ErrorDialog like SettingsDialog is kept as a standalone class and can be used as follow

JmeSystem.setErrorMessageHandler((message)->{
   ErrorDialog.showDialog(message);
});

That’s all, please leave your feedbacks here or on github and let me know if you have any objection to these changes.

10 Likes
2

Note: except for 1750, none of these changes will be in JME 3.5, which is 5 days away from code freeze.

The proposed changes to startup configuration and error handling won’t take effect until 3.6 at the soonest.

2 Likes
3

AKA: breaks every single existing JME app that shows the settings dialog.

So the existing automatic error popups will go away silently, breaking the standard error reporting for any app that hasn’t overridden this behavior.

Just want to make it clear to everyone reading that you are proposing breaking pretty much all existing JME apps just to support Macs (which many devs won’t have the resources to jump through the hoops to properly deploy on anyway) rather than some specific Mac-compatibility that must be turned on (and is technically already available).

It’s the last one I’m particularly worried about. Silently stopping reporting errors to the user is a big deal.

At least running the application without a settings dialog and potentially totally awful settings is obvious.

2 Likes
4

AWT to SWT? That would be safer option?

5

Nice. I can finally switch JME’s default error dialog with Lemur dialog and get rid of the GLFW + AWT issue on Linux as well.

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  20 (X_GetProperty)
  Resource id in failed request:  0x4e0005b
  Serial number of failed request:  1332
  Current serial number in output stream:  1332

It also affects Linux.

2 Likes
6

Only if every JME app that shows the settings dialog needs the settings dialog. Lots of apps show the settings dialog only because it’s shown by default. That doesn’t mean changing the default will break those apps.

Again, I think that’s a very odd way to look at the change. Lots of apps don’t care how errors are reported.

1 Like
7

Just a note that you could already do this. The problem is that for this kind of error, JME rendering may not be around any more to show it.

2 Likes
8

Just in case, it might be worth mentioning that in Java 17 AWT/Swing switched to use Metal for its backend on Mac which might already fix issues with Mac. I do not have a Mac to test it though.

1 Like
9

Ok, I can’t speak for everyone else like you can. I just know that it will break about 20 of my apps where I DO rely on the settings dialog to try different settings… whether screen size or just vsync.

Nonononon… you don’t understand me. An app not run from the command line will present no errors at all. It DOES present errors now. Run it, do something, silently crashes. Why? Who knows?

It’s just a shame that some default behavior cannot be maintained in the interest of fixing MacOs. I wonder how many people will delay upgrading JME versus how many people will be hit by the MacOS issues for their apps.

Apple has become very developer-hostile, especially to OpenGL apps. It’s a shame to break any regular user just to support the issues there.

I hear you. And I feel like I’ve brought that up in other threads relating to problems with glfw, etc… and been given the impression that I’m either wrong or it’s not as big of an issue.

1 Like
10

I think it’s better not to use any other graphical library that is not opengl by default, launchers/settings dialogs can be maintained as separated modules for the engine.

If your app needs those dialogs you can always add the two lines of code to restore them when you update to the newer version of the engine

Errors will be still reported on the terminal by default

1 Like
11

What terminal? When I double click an icon, I get no terminal.

Too much work to switch all of my apps… I’ll probably just stick with the last version that has a settings dialog.

No big deal, really. But I suspect I won’t be the only one to just wait going forward.

Edit: on the other hand, if we are fine with breaking changes that will cause users to have to update their code just to get things working again… maybe we can finally get rid of the shitty default fly cam integration?!?

1 Like
12

This dialog causes issues also on some linux systems. I’ve seen it being rendered unusable by poorly applied dark theme, being unresponsive and causing the mouse to not be released on fullscreen apps

13

Would it be possible to provide good defaults so that most apps can be launched without tweaking any setting?

Eg.

  • Fullscreen
  • Current monitor’s native resolution
  • sRGB on
  • 60 Hz
  • 24bpp color
  • 2x MSAA
2 Likes
14

Full screen should not be the default, I think… nor should MSAA if apps haven’t configured filter post processor already.

I think vsync should be the default. Forced 60 hz is wasting cycles.

But it won’t matter for me, I rely on the settings dialog to flip different settings on different days for different needs. So I’ll just stick with 3.5 for the foreseeable future.

Edit: with luck, maybe lwjgl will switch to something less broken than glfw at some point in the future and I can readdress.

2 Likes
15

i understand that it’s just defaults, but due to multiple monitor, i think fullscreen do not sound nice.

But generally many people do not change this settings initially, so i suppose its good idea to setup better ones.

16

Mhh ok, but why is fullscreen an issue with multiple monitors?

17

I realise steam is not the world, but steam also HATES the JME settings dialog (It puts an overlay over it that seems to corrupt it; I think because parts of it don’t realise they need to refresh after the overlay goes away) which is what finally pushed me to stop showing it and replacing it with a config file.

Similarly because I want to kick open a “do you want to report this error” page that sends off errors to a webservice endpoint the change to add a JmeSystem.setErrorMessageHandler would actually be a nice improvement for me as it would make that easier.

Will there be a migration guide? These changes don’t seem that frightening for a 3.6 release (And I say that as someone who isn’t currently releasing on mac and so won’t get any direct benefit from them)

2 Likes
18

not an issue, i just think if game would run on “wrong” monitor for new developer, he might be confused. With a window, he can just move it.

Also anyway i seen some games use “borderless fullscreen window” without even real “fullscreen” option. Do you maybe know why they do this way?

1 Like
19

What about using 1280x720 HD resolution?

2 Likes
20

Right, makes sense. I’ve never had this issue, but it might exist in some configurations.

I think probably because fullscreen is a concept specific to the window manager, it might give the fullscreen window exclusive access to mouse focus, pause/bypass the compositor and make alt tab harder or more prone to bugs, also it might span or replicate across multiple monitors. I think by default glfw uses a borderless window for fullscreen (or so it was last time i checked, it might have changed since exclusive fullscreen gives better performances on lowend devices).

Yeah or maybe proportional to the display size?
eg. if window size is not set:
if size < 1280x720 → default to 640x480
else if size/2 > 1280x720 → default to size /2
else default to 1280x720

1 Like