This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.1
Reported for operating system, platform: Other, x86

Comments on the original bug report:

On 2013-11-11 02:01:59 +0000, Alex Szpakowski wrote:

Mac OS 10.7 introduced a new type of fullscreen for windows, and it's very much user-controlled. When enabled for the window, a button automatically appears at the top right of the window decorations to toggle it. Most programs also have a toggle in the 'view' menu in the menubar.

I think this new type of fullscreen fits in nicely with SDL's resizable windows, since the window will get auto-resized to fill the whole screen (and enter its own Space) when the button is pressed.

It's fairly trivial to change SDL_cocoawindow.m to make the button appear when the window is created as resizable, but there are some issues I have not been able to resolve myself. If SDL_SetWindowFullscreen is called while the window is either in the 10.7+ fullscreen mode or transitioning to or from it (which takes some time), corruption issues, crashes, or other visual bugs might happen.

I'm not sure how to handle that situation properly. It is possible to exit the 10.7+ fullscreen when the window code attempts to enter "real" fullscreen (display mode or fullscreen desktop versions), but that still takes several tenths of a second and I don't know if attempting to block while that's going on is the right solution - event pumping still needs to happen.

To make the button appear, this has to be called after the NSWindow is created:
[nswindow setCollectionBehavior:NSWindowCollectionBehaviorFullScreenPrimary];

More docs (including events which are triggered when various 10.7+fullscreen situations happen) are here:
https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/FullScreenApp/FullScreenApp.html

On 2013-11-11 11:07:07 +0000, Sam Lantinga wrote:

Done!
https://hg.libsdl.org/SDL/rev/5ac1a895b313

On 2013-11-11 11:25:33 +0000, Alex Szpakowski wrote:

Sweet!

There are a few issues I've noticed so far when testing:

• When the mouse is moved to the top of the screen (where the menubar normally is) in FULLSCREEN_DESKTOP mode, it causes a short stutter in performance. This is only happening now that a FULLSCREEN_DESKTOP window is always in its own Space, probably because the menubar is being automatically shown behind it.

• If a window is not resizable, the fullscreen button is still there. This would be fine because the window doesn't fill the entire screen when the button is pressed if it's not resizable, but what does happen is the area normally taken up by the window decoration is converted into renderable space, so the window does actually resize slightly when it's not supposed to be resizable.

• Again when a window is not resizable and it's in its own Space via the Fullscreen button, toggling FULLSCREEN_DESKTOP doesn't work properly (on the first toggle it doesn't fill the space completely.)

• As above, if the window is not resizable and is in its own Space via the Fullscreen button, toggling SDL_WINDOW_FULLSCREEN (display mode switching) and then toggling back will make the window move to the top left corner instead of being centered.

• If the window starts out as normal non-resizable and FULLSCREEN_DESKTOP is set via SDL_SetWindowFullscreen, the top menubar is now accessible when the user mouses over it (this is different from the old behaviour.)
  If the user presses the exit fullscreen button from said menubar, the window's decorations do not appear properly and I get some rendering glitches.

On 2013-11-11 11:32:57 +0000, Sam Lantinga wrote:

Great testing!
I'm heading to bed, but feel free to get the latest code (I fixed some compile issues) and submit fixes! :)

On 2013-11-11 12:01:18 +0000, Alex Szpakowski wrote:

I'm not sure I'd be able to nail these issues (at least with my current level of experience with Cocoa/ObjC).

I found more bugs already - I feel like this feature might need to be re-implemented in a different way, it breaks quite a lot of things as-is. If the issues can't be resolved nicely then personally I'd rather stick with the old code for now.

More issues:

• If I destroy a window that is in its own fullscreen Space, I get this debug message from Cocoa in stdout:
  [6747:507] not in fullscreen state

• If I immediately recreate a new non-fullscreen window after destroying the one that was in a fullscreen Space, sometimes the view doesn't switch away from the now-empty Space until I manually do it.

• Sometimes after exiting display-mode fullscreen if the window was in Space-mode fullscreen before switching to display-mode fullscreen, on top of the previously mentioned issues, clicking the program icon in the Dock won't take you to its window (which is stuck in its own Space.)

On 2013-11-12 09:55:20 +0000, Sam Lantinga wrote:

Okay, I did a bunch of testing and it looks like this doesn't coexist well with the standard fullscreen mode code, so I added a hint for people to be able to switch between behaviors: SDL_HINT_VIDEO_FULLSCREEN_SPACES

It doesn't work well yet with multiple windows, but this is a good start for someone doing a game and wanting to use the new style fullscreen mode.

Can you take a look?

On 2014-03-03 06:12:07 +0000, Sam Lantinga wrote:

Shipping for 2.0.2! :)