[macOS] Incorrect behavior with full screen hotkey

[nadiaholmquist]

Describe the bug When using the hotkey to enter full screen, ares seems to enter full screen mode incorrectly on macOS. When using the button on the title bar instead, full screen seems to work correctly.

• The full screen window does not get its own Space/virtual desktop like other applications in full screen do
• Keyboard input gets registered when the full screen window is not in focus
  • Happens even when the permission to monitor keyboard input is not granted
  • Seems to disregard the option to block input when unfocused
• The close/minimize/maximize buttons disappear when restoring the window from fullscreen (macOS 10.15+ bug? according to SDL2 source code)

To Reproduce

1. Bind a hotkey to toggle full screen
2. Press the hotkey to trigger the incorrect full screen behavior

Expected behavior ares should enter full screen the same way regardless of whether the button on the title bar or the full screen hotkey is used.

Screenshots https://github.com/ares-emulator/ares/assets/893884/6a2546ab-76db-4a5d-9408-8352d090e520 Here is a screen recording showing the issue. The first time I full screen, I use the button on the title bar, and the second time I use the hotkey.

Additional context ares v138, also reproducible in latest commit. macOS 14.4.1 on Apple Silicon

[jcm93]

Hello, thanks a lot for the report!

(the fullscreen behavior here is unique to the Metal driver, for reference)

The input issues I will take a look at and try to solve as they are certainly not intended.

The implementation of fullscreen here is a bit awkward, and needs to be worked on. However, having this presentation behavior here, at least as an option, is actually intentional.

macOS idiomatic fullscreen, with the application in its own Space, would ideally be the only fullscreen mode. But it has several limitations. Primarily, it is not possible to use idiomatic fullscreen to actually fill the entire screen on newer Macs with a camera housing (notch) at the top of the display. The hidden title bar impinges on the available screen real estate, no matter what. The custom fullscreen presentation here (which is actually common to a lot of games and emulators on macOS), uses a borderless window with a frame equal to the size of the screen. This is the only way to actually use that space. Attempting to create a borderless window with a frame set to the size of the screen in combination with system fullscreen results in highly broken behavior that seems largely the result of a macOS-side bug.

Secondly, ares does not currently hide the mouse cursor outside of either the fullscreen hotkey, or mouse capture for systems and titles that support mouse input. The presence of the mouse cursor in macOS fullscreen results in degraded performance and frame pacing for the fullscreen application because of another macOS issue. Since there is not currently a way in ares to hide the mouse cursor in system fullscreen, but it is hidden when using the fullscreen toggle, that is what was shipped in this iteration.

Overall, the thinking here was "keep idiomatic fullscreen available with the window controls, but use our own implementation if we want optimal presentation." Currently, this isn't clearly communicated, and you're certainly correct that the application should only have one behavior at a time.

I can see a couple routes forward. The driver could try to detect if you are on a display with a camera housing, and then offer an option for your preferred fullscreen behavior if you are, and simply always use system fullscreen if you are on a normal display without a notch.

That also however needs to be unified with a proper paradigm for hiding and unhiding the mouse cursor. Unless the cursor is being used, it needs to be hidden in fullscreen for acceptable frame pacing. https://github.com/ares-emulator/ares/pull/1328 exists, but has not been merged, and may possibly need a rework to more elegantly account for things like mouse capture (which separately hides the cursor) or the fullscreen option itself.

I'll keep thinking about it as I write fixes, and please feel free to share your opinions as well; I primarily wrote the driver with my own requirements in mind so it's always good to hear feedback.

[nadiaholmquist]

Wow, thanks for the detailed response!

I'm curious if you have tried if the visible mouse cursor frame pacing issues still happen in macOS 14.4.1? I had reported an issue about bad frame pacing to Apple through Feedback Assistance, and I recently got a response that they had resolved a similar issue in 14.4.1 but with no information as to exactly what changed, so maybe we're lucky here?

The compromise of using native fullscreen on non-notched displays seems like a reasonable choice to me. The users that would benefit the most from the native fullscreen working as expected is probably those on desktop displays anyway. One could hope the bug that causes this to be needed in the first place would be fixed eventually, but this is Apple we're talking about so let's not get too optimistic...

[jcm93]

Can you provide any more detail on the input issues? Which input driver and which keys? I'm only able to reproduce the issue here with the return key; all other keys I've tried seem to function as expected and aren't picked up when the app is defocused if 'allow input' isn't set. Looking into that, but wondering if you are seeing it with all other keys, etc.

[nadiaholmquist]

I'm using the SDL input driver because the other one doesn't work with my controller.

It seems like Enter and Tab are being picked up even when inactive, but the other controls that I have bound to alphanumeric keys do not.

[jcm93]

139 just came out which addresses issues with the fullscreen behavior.

I was looking into the key issues with return and tab, but I hit a dead end where I started seeing inconsistency in whether it would occur. It's still on my radar though.