MAC OS X: Alt+Enter may freeze/crash app if switching from windowed mode to fullscreen mode.

[macca8]

This issue appears to be restricted to buildbot’s daily builds (developmental & stable), and not all versions of OS X are affected (in my case, 10.11.6 is, but not 10.6.8).

Importantly, v2.0.0 release builds are unaffected, so hopefully the issue isn’t transferrable to the upcoming v2.1.0 release.

It’s been around for a while, and is triggered by using Alt+Enter to switch from fullscreen to windowed mode, then back again, and then repeating this sequence sometime during the current session.

In the first instance, the transition from fullscreen to windowed to fullscreen works as expected.
However, any subsequent attempt to repeat this sequence results in the app’s window freezing when the user attempts to return from windowed mode to fullscreen.

At this point, the ScummVM/game cursor is frozen in place within the app’s window, and the system cursor is hidden from view, but remains active. Scrolling the mouse to the bottom of the screen will make the system cursor reappear when it encounters the dock.

Once revealed, the user can interact with all items in the ScummVM application menu (though Quit is unresponsive) and ScummVM’s dock icon (enabling Force Quit), but not with objects within the bounds of the app’s window.

In most cases, the window will simply freeze, but if the app shifts between foreground and background while in windowed mode (for example, when viewing Help items), then returned to fullscreen, a random crash may occur instead of a freeze, but not always.

With regard to freezes, the OS X console message is always the same type, though the offending item may vary:
19/09/2019 2:28:11.932 PM scummvm[xxx]: -[_NSCFDictionary objectAtIndex:]: unrecognized selector sent to instance 0x3347990

Other examples: _NSCFNumber count, _NSCFString count, _CFXNotificationTokenRegistration count.

With regard to crashes, the message is always:
19/09/2019 3:02:46.101 PM com.apple.xpc.launchd[x]: (org.scummvm.scummvm.171552[xxx]) Service exited due to signal: Segmentation fault: 11

The effect of using Alt+Enter is cumulative, and it doesn’t matter whether it’s used in the Launcher or a game screen.

The easiest way to test if your version of OS X is affected is by using Alt+Enter to perform consecutive screen changes; 4 times if starting from fullscreen, or 5 times if starting from windowed. If it’s going to freeze, it should do so on the final change.

Having said that, there’s a reasonable chance that this may be a local issue, since I have another unresolved issue involving OS X 10.11.6 (#10371) which apparently others cannot replicate.

Daily stable version: 2.1.0git8384-g52166aa3b1(Sep 19 2019 16:05:27)
Platform: Intel Mac (OS X 10.11.6)

[angstsmurf]

This is similar to #6755, which seems to happen on all versions of macOS since at least 10.9 if ScummVM is compiled with SDL 1.2.

[macca8]

Thanks for the feedback… the other link is indeed similar.

My only query involves the 32bit v2.0.0 release build, which is unaffected by this issue.
Criezy clearly states in the linked report that the v1.9.0 release was built with SDL2, without differentiating between 32bit & 64bit builds.

Is the 32bit release actually built with SDL2, and not SDL1.2, even though its screen appearance matches that of the SDL1.2-based daily builds (i.e. black bars surrounding Launcher)?

I did ask this question in my other post, but never received an answer.

[criezy]

Yes, the 32 bits 2.0.0 release is build using SDL2 (2.0.4 to be precise, since 2.0.5 dropped support for OS X 10.5 - the 64 bits releases uses a more recent SDL2 version).

So this issue is likely again the same one as #6755. But I will keep this one open a bit longer until we have a daily build that uses SDL2. In the meantime I created a test 64 bits 2.1.0 version with SDL2 today: ​https://www.dropbox.com/s/iwgdxleh9rhxbqc/ScummVM-2.1.0-c2f6eb6-macosx.dmg?dl=0

[macca8]

Thanks for the explanation criezy, and the opportunity to try the 64bit test build. As expected, this issue isn’t present with SDL2.

In other good news, the secondary issue I raised in #10371 regarding the misbehaving Enter key on full-size keyboards is also resolved… Alt+Enter now functions the same as Alt+Return.

Unfortunately, the double cursor issue described in #10371 is still present, though it's easy enough to avoid.

There is one bit of odd behaviour in the test build though, that’s not present in the 64bit v2.0.0.1 release.

Clicking Return to Launcher in the GMM to return to a fullscreen Launcher generates a black screen with just the system cursor displayed.

This had me confused for a while, until I realised that I only had to move the cursor to reveal the Launcher hidden underneath. Launcher to game works as expected.

[criezy]

I have another build ready to test that uses the latest SDL version (the one from yesterday uses a slightly older SDL): ​https://www.dropbox.com/s/hnlkct9hz46hugg/ScummVM-2.1.0pre-fac4686-macosx.dmg?dl=0

Feedback on this version is welcome as I have not yet decided whether I am going to switch to this new SDL or not for the release.

I tried reproducing the cursor issues you describe in #10371, and I can't reproduce it (not with my build from yesterday, not the new one).

However I do reproduce the issue that the black screen until you move the cursor when you return to the launcher in fullscreen mode (and non-OpenGL graphics mode - with OpenGL it works properly). This issue for me happens both with the build from yesterday and the one from today, so unfortunately the new version of SDL does not fix it (I don't even know at this point if this is a bug in SDL or in issue in our code). This issue is not critical, but it is indeed confusing.

[macca8]

As with the first test build, the 2.1.0pre test build resolves the Alt+Enter & Enter key issues. For me, the double cursor issue remains (non-OpenGL graphics modes only, as reported originally).

Where it does differ is in the situations where it consistently generates the black-screen-covering-a-fullscreen-Launcher issue (I confirm that OpenGL is not affected by this issue).

Bearing in mind that the slightest movement of the cursor will reveal the Launcher, there’s only two instances in the 2.1.0pre test build where the black screen is consistently generated:

• The app opens to a fullscreen Launcher when double-clicked (excludes the first launch since booting up your computer).
• Returning to a fullscreen Launcher from a windowed mode game (using Alt+Enter to switch the game to fullscreen before returning will prevent the issue).

Unlike the first test build, returning from fullscreen game to fullscreen Launcher no longer generates the black screen, so that’s a significant improvement, which suggests to me that this issue is indeed a bug in SDL, which has been addressed (at least in part) in the latest version of SDL.

Of course, there’s always exceptions, which may be random, but generally, they're a one-off that's limited to the first return to Launcher from the next game launched after any of these events:

• after changing Graphics options.
• after the first time use of Alt+Enter in the Launcher.
• after restarting the app, having previously quit from in-game.

I’ve probably gone into too much detail, given that it all can be resolved by simply moving the mouse, but hopefully it helps.

[criezy]

As the original issue reported here is related to the SDL version, and we now have 64 bits nightly builds with SDL2, I am now closing this.

[macca8]

In a strange twist, it appears that the black screen issue is restricted to the official 64bit v2.1.0 release (and associated test builds).

Buildbot's 64bit daily builds (developmental & stable) - which apparently are using the same version of SDL - don't have this issue.
The only obvious difference is that these builds are using a different font for menus & lists to that used by the official releases (32bit & 64bit) & the 32bit daily builds.