[Mac] Fullscreen modes not scaled to screen size

[BlueCobold]

Hi.

I'm using master branch SFML on OS X 10.10 and when setting fullscreen-modes with a resolution smaller than my desktop resolution, I get a small window in the middle of the screen and large black areas around it. It doesn't get scaled to the full screen size on OS X, but it does scale to the full screen on Win7. Other games on OS X in fullscreen do scale properly, just SFML doesn't. The smaller resolution I chose, the smaller gets the displayed window in the center of my screen. The used resolutions are valid fullscreen-modes and are retained/confirmed via sf::VideoMode::getFullscreenModes().
What am I missing? I am not using multiple monitors or something.

Edit: The sf::Mouse::getPosition() call does return 0/0 for the left upper point of the screen, but not when moving it to the area at which my SFML-window is displayed. When using an 800x600 window on a 1440x900 screen, the upper left coordinate where my window is displayed returns a mouse-coordinate of 320/150. That I can even move the mouse outside of the area at which my window is displayed, feels odd.

Greetings.

[Hiura]

It was a design choice some time ago. What I won't do, because of Apple's policy (*), is perform a hard switch as it's currently done on Windows. Actually, the Linux impl is being revised to follow the same behaviour.

But should the view be stretched to fit the screen (with proper ratio), or should it use letterboxing? That question is still open to discussion since I had not enough feedback when implementing fullscreen support.


(*)

Avoid changing the display resolution from that chosen by the user.

(Source)

[eXpl0it3r]

If you don't scale the window at all, then what's the point of specifying a different resolution?
I mean if it's just a question of maintaining the ratio or fully stretching it, then I guess one could discuss this, but otherwise when I request a 800x600 resolution in fullscreen, I want this to actually scale to my "full screen".

[Hiura]

when I request a 800x600 resolution in fullscreen, I want this to actually scale to my "full screen".

That's a valid point.

But the question remains: should it be scaled to fit the screen with the proper ratio (with letterboxing), or just stretched.

I feel keeping a letterboxing solution -- but not a mini window -- would be better. Having something distorted just to fill the screen is really ugly and since we don't provide any monitor API (yet) the dev has no idea of the actual ratio of the display so (s)he cannot choose automatically a proper video mode.

Another solution would be to introduce more specialised fullscreen flag such as HardSwitchFullscreen which would result in a fully stretched window.

[Tank]

I would not automatically do letterboxing. A monitor API isn't needed as well: If you set 800*600, then you can simply do letterboxing yourself, since you now how to transform it to maintain the correct ratio.

I don't think that SFML should interfere with this. I've never seen this happening elsewhere, and I really would not expect SFML to "fix" my things without me explicitly saying so.

[Hiura]

I would have to search again for it but if remember correctly at least one guy complained about the screen being stretched... So I'm *really* interested in everybody's opinion on the subject as I am myself not on any side (yet).

If I've got only one guy every two years or so complaining about my impl, I just have no idea if I'm doing my job right or not. 

[binary1248]

Requirements change, and I guess the hardest part for us is judging from the opinions (if any ) of the community what those requirements are.

As a general rule of thumb, I like to say: The effort required to perform a task should be inversely proportional to the frequency in which that task has to be performed.

This in my opinion leads to wide acceptance and usability of an API. The important thing to remember as well, is to always allow users to do what they want (i.e. not limit them in any way), no matter how crazy it is . The effort it should take them to do what they want, the rule above already explains.

I don't think it is safe to assume that a single individual complaining about stretching is enough to warrant the library being designed around that sole individual's requirements. If you look at all operating systems and their users, this really becomes just another edge case. I haven't experienced first-hand any letterboxed fullscreen applications/games on Windows/Linux yet, and even in videos of such games, it is a generally accepted opinion that the developer just didn't want to give the extra effort to support "real fullscreen" properly .

[eXpl0it3r]

As said on GitHub I think it should probably fully expand. If I go fullscreen, I'd personally expect that I get every last pixel on the monitor to manipulate. Sure if the resolution doesn't match you might get odd scaling, however this is a development issue and not a graphics library issue.
Maybe one could compare it a bit to the sf::View. If you scale the window SFML won't just keep the view's ratio and it won't stay the same size as it was before, instead it's "attached" to the window itself and will scale with the resizing window.

I mean sure automatic letter boxing can be useful if you're too lazy to adjust the view yourself or if you don't know how to support proper fullscreen mode. But from my point of view it's effectively making decisions for the developers and thus limiting them in a certain way.

[dabbertorres]

I haven't experienced first-hand any letterboxed fullscreen applications/games on Windows/Linux yet, and even in videos of such games, it is a generally accepted opinion that the developer just didn't want to give the extra effort to support "real fullscreen" properly .

Just to add to this... The game, Faster Than Light (great game btw), which (iirc) uses SDL (1.2 is the version of the lib shipped with the game), and runs on Windows, OSX, Linux, offers 4 options for windowing.
1. Windowed mode
2. Fullscreen Stretch
3. Fullscreen Border
4. Fullscreen Native

Windowed mode works as expected.
Stretch works as expected, stretching the game to fit the monitor, then letterboxing as needed to keep the game's aspect ration (16:9).
Border works as expected, letterboxing the game.
Native though, changes the native resolution of the monitor to the game's resolution and turns off any other monitors.

This is all on Linux; Windows behaves similarly. Don't know about OSX.

I'm not sure of the inner workings of the game to support all of these options, but, SFML, in the past at least, has always done #4 on Linux. Which, as a user, I consider to be the least favorable, since I have to go and reset my display settings in my WM afterwards. It also seems to ignore my primary monitor setting.
Stretch, is what I consider to be the best option, though Border could be fine. I'm just not a fan of letterboxing.

As a programmer though, I think having options like FTL does would be best. So, a style flag for each:

sf::Style::FullscreenStretch - would stretch to fill the monitor. If the programmer wants to then letterbox to match an aspect ratio, leave it up to them
sf::Style::FullscreenBorder - letterbox completely
sf::Style::FullscreenNative - not preferred, but, would do the "hard switch" that has been mentioned if I understood correctly

Would be best in my opinion. I don't know how much work this entails, as I don't know Xlib or XCB very well, but that would be my preference. I'd be happy to learn and help with it if needed though.


tl;dr: As a user, I prefer stretch fullscreen, and not having my resolution and monitor settings adjusted by the program.

[BlueCobold]

Avoid changing the display resolution from that chosen by the user.

(Source)

I don't want to change the games resolution without asking the user. The user will change it on his own demand by using an ingame-option-menu. Allowing the user to change the resolution, does not violate this policy at all. A graphics library though shouldn't care about any policies from Apple at all (at least in this case), it is the developer who uses the library who has to make sure he complies to it. The library only should provide the technical possibility to the developer who is using it.

However, I do not expect any letterboxing to happen either. If I want fullscreen, I expect the full screen to be used. Letterboxing isn't really full screen. And if the user selects a mode which doesn't fit the screen aspect ratio, the game would need to take care of that, not the fullscreen mode. If it doesn't want bad aspect-ratios, it shouldn't allow these to be used.

It would be fine by me if internally SFML would use desktop resolution and only scale the chosen resolution to the full screen. Looks like Diablo 3 is doing the same (the screenshots are 2880x1800 even in 1920x1200 fullscreen resolution).

PS: The mouse-coordinates should also be scaled when using the stretch-to-full-thing

[Hiura]

There is something I remember now that I need to add while other continue posting their opinion: on OS X, a hard switch will result in a (potentially scaled) view that is not stretched. Regarding the UX on that OS, having a stretched view is not necessarily what the developer might expect. However, a dev working on multiple OS might like a library that has the same behaviour on all platform. So all in all I don't mind either way.

But if we don't perform a hard switch, on OS X, Linux or Windows, the next question is what should getFullscreenModes return. I guess if we introduce HardSwitchFullscreen we are fine, with perhaps a LetterboxedFullscreen mode too (that scales but not stretches).

[BlueCobold]

Well, I'm using SFML for a game on Windows, OS X and iPad (plus Android in some time). That's why I don't like what the current OS X implementation does in regard to fullscreen-modes. How this will be solved I don't really bother with. I'm fine with a hard switch and also with a stretched mode. I guess stretching would cause less issues for SFML in case of a crash or when alt+tabbing out of the application. Since Blizzard seems to also just stretch, sounds like a plausible way to me.

[BlueCobold]

So what's up with that? Is there anything planned or will it require me to implement my own stuff to do proper fullscreen display? Just that I know if I should wait or just go for it myself.

[Hiura]

Since the discussion is quite long and comments are scattered in various places, let's try to recap with a proposition. Please tell me if it makes everybody happy. 

I'd say we should introduce a second fullscreen style flag:

• one for hard switch, and
• one for soft switch which would fill most of the screen without stretching (i.e. it would respect the ratio asked by the user).

[BlueCobold]

That would be the perfect solution.