| Summary: | Mac: cmd-tab doesn't work in fullscreen mode | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Alex Szpakowski <amaranth72> |
| Component: | video | Assignee: | (disabled) Jørgen Tjernø <jorgen> |
| Status: | RESOLVED WONTFIX | QA Contact: | Sam Lantinga <slouken> |
| Severity: | minor | ||
| Priority: | P2 | CC: | buckyballreaction |
| Version: | HG 2.0 | ||
| Hardware: | x86_64 | ||
| OS: | Mac OS X 10.8 | ||
|
Description
Alex Szpakowski
2013-06-10 20:49:43 UTC
Hey Jorgen, what was the result of your Mac fullscreen investigation? I did a bit of investigating myself. Some of my findings: • I don't believe there is a way to nicely have command-tab/minimization/exposé support with the old <= 10.5 fullscreen Mode API. • The new recommended way is to create a borderless fullscreen window and set the OpenGL context backbuffer dimensions to the requested screen size - it will be automatically scaled up when the backbuffer is drawn to the screen. It appears to actually be supported down to OS 10.3, but the Apple docs imply it only gets the performance benefit of normal fullscreen in >= 10.6. • The new recommended way has some implications: - The resolution cannot be larger than the current desktop mode resolution. This isn't necessarily a bad thing, but it's a change from the current API. - Because the backbuffer is automatically scaled up to the full window size, it will always stretch to completely fill the screen instead of maintaining its aspect ratio with black borders, unless code is written to explicitly do that. This is another change from the current API, and personally I'd much rather the black borders than stretching. - Mouse coordinates (etc.) would need to be scaled from the window dimensions to the requested screen size and vice versa, when going between Cocoa and the program using SDL. This would get a bit more complicated if black borders were added for non-native aspect ratios. - I don't have a Retina Mac so I don't know how the retina scaling would be dealt with (if at all) using this technique. Probably worth further investigation. • Because this method is just creating a standard window without borders, the new fullscreen mechanisms added in 10.7 compliment this method rather than replace it. Having the new method automatically use 10.7's fullscreen when supported seems to be rather simple to implement, which is nice. Mac OS 10.9 is significantly improving the fullscreen experience added in 10.7, so this seems like the way forward. Also, I am not sure how this would all work out for SDL programs *not* using OpenGL - I haven't looked into that at all. Does SDL in OS X already always use an OpenGL context internally? If not, two separate code paths might be needed if the new fullscreen method does end up being used for OpenGL. I think this issue might be the same as the bugs I've encountered, and mentioned on the mailing list: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-July/089121.html If not, I can open a different bug I had my hopes that resolution of bug #1996, which was fixed recently, might solve this bug. Sadly it didn't. CMD + H in an OpenGL fullscreen window still produces a black screen (on OSX 10.6) and fails to minimize it. . It's not really a bug in SDL's code - it's just the way the old OS X display capture method works. You should probably either always use SDL_WINDOW_FULLSCREEN_DESKTOP or detect command-M, command-H, and command-tab keypresses and un-fullscreen the window manually (Awesomenauts does this and it works ok.) My goodness, you're right! SDL_WINDOW_FULLSCREEN_DESKTOP works like a charm. How did I miss this? We already do graphic scaling, etc., so this was perfect. Thanks! |