We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2223 - Mac: enable the fullscreen button in 10.7+ for resizable windows
Summary: Mac: enable the fullscreen button in 10.7+ for resizable windows
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.1
Hardware: x86 Other
: P2 enhancement
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-11 02:01 UTC by Alex Szpakowski
Modified: 2014-03-03 06:12 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Szpakowski 2013-11-11 02:01:59 UTC 
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
Comment 1 Sam Lantinga 2013-11-11 11:07:07 UTC 
Done!
https://hg.libsdl.org/SDL/rev/5ac1a895b313
Comment 2 Alex Szpakowski 2013-11-11 11:25:33 UTC 
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.
Comment 3 Sam Lantinga 2013-11-11 11:32:57 UTC 
Great testing!
I'm heading to bed, but feel free to get the latest code (I fixed some compile issues) and submit fixes! :)
Comment 4 Alex Szpakowski 2013-11-11 12:01:18 UTC 
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.)
Comment 5 Sam Lantinga 2013-11-12 09:55:20 UTC 
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?
Comment 6 Sam Lantinga 2014-03-03 06:12:07 UTC 
Shipping for 2.0.2! :)