Adjusted WindowImplX11.

[TankOs]

• Replaced Xlib event names by XCB equivalents.
• Removed XCB_CW_OVERRIDE_REDIRECT in order to let the WM handle mapping the window to the full screen.
• Fixed mouse grabbing in fullscreen mode. Removed keyboard grabbing to allow the user to "alt+tab" out of the window.
• Completely revised fullscreen handling: The screen's resolution is not changed at all anymore. Instead the WM is asked for going fullscreen and the view is scaled.

[TankOs]

Related issues: #771, #724, #535, #274

[mantognini]

Completely revised fullscreen handling: The screen's resolution is not changed at all anymore. Instead the WM is asked for going fullscreen and the view is scaled.

Does that mean the view is stretched or is it letterboxed?

[LaurentGomila]

Completely revised fullscreen handling: The screen's resolution is not changed at all anymore. Instead the WM is asked for going fullscreen and the view is scaled.

So you always stay at desktop resolution? This defeats one of the advantages of the fullscreen mode (ie. taking control on the screen resolution).

[mantognini]

On Mac, SFML 1.6 used to perform a hard switch but that's no longer the case for two main reasons: a) performances were not significantly better with a hard video mode switch than with backbuffer/letterboxed view; b) Apple's discourage this practice. See 8f0037d for more details.

While b) might not hold on Linux per se, I think it's also better to avoid messing with the user's desktop settings (with some WM, windows are resized and icons moved on the desktop). However, we could argue that's up to the application developer to choose wisely a fullscreen config...

But I'm pretty sure the first point holds. Could someone confirm it?

@LaurentGomila maybe you see another aspect in favor of hard switch beside UX and perfs?

[LaurentGomila]

Mainly performances, yes, even if this point is less important nowadays.

[TankOs]

@mantognini
It is stretched, because that's what would happen in classic fullscreen as well.

@LaurentGomila @mantognini
What performance issue are you referring to? The upscaling? If yes, then I doubt it will be an issue on any supported hardware.

If you are referring to some kind of exclusive mode: There is no such thing on Linux/X/GLX.

In fact the new implementation fixes some issues and allows to easily tab out of the window without resolution change parties. ;) Personally I don't see a real reason to change the screen resolution anymore. Quite some games are doing the same on Linux mainly for avoiding issues.

[mantognini]

My point was that performance was not an issue, so, for me, your new impl is ok.

Well, up to a point. ;)

I feel, as other users who made me change the impl on OS X (see above commit link), that when you ask for a 800x600 view, full screen or not, you should get a 800x600 view -- not something that is reported as such but is in fact stretched -- for the sake of UX.

Also, on OS X, if you perform a hard video mode change to 800x600 you get a rect with the correct ratio. Isn't that not also the case on Linux? If that's the case, the view the user get through SFML should match that ratio -- whether SFML performs a hard or soft switch. If that not the case, I think it's reasonable to do it anyway.

[def8x]

After shortly experimenting with it, I must say I am definitely in favor of this new implementation, even if it does not really respect the specified video mode. Performance issues can still somewhat be worked around by using a smaller sf::RenderTexture, which is then upscaled and drawn as a sprite.
In addition to fixing the mentioned issues, these adjustments also greatly improve support for multi-monitor systems by opening the fullscreen window on the monitor the mouse is currently at (under xfwm4 with TwinView) with the respective monitor's native resolution.
Previously, SFML would show fullscreen windows at an incompatible resolution (1920x1080 on a 1280x1080 monitor) on an arbitrary monitor (probably just the first one returned by xrandr).

However, there is currently a bug on my system (or my code?) where using sf::Style::Fullscreen either in the first call to create() or the constructor of sf::Window silently fails, instead resulting in a regular window with a grabbed mouse cursor:
sf::RenderWindow window(sf::VideoMode(640, 480), "Title", sf::Style::Fullscreen);

It is required to call the create() function one more time to actually make the window full-screen. Can anyone else reproduce this?

[TankOs]

@mantognini
You effectively get 800x600 -- in fact it is stretched to 800x600. ;) The result is nearest to the previous behavior when the monitor handled the upscaling, that's why I haven't added anything on top of that. I wasn't aware that it's done differently on OSX.

I'm not sure if I want to enforce a ratio. I can also find nothing about that in the documentation. Remember that if you force a letter box/correct ratio, there's no way for the user to NOT use it, for whatever reason. I think this should at least be an option. I would not expect a ratio correction personally.

@def8x
Yes definitely, I forgot to mention the multi-head advantage. Since I'm using two heads, I was happy to see a resolution of 1920x1080 working on both screens, where the 2nd screen allows a maximum of 1280x1024 only. :)

I will try to reproduce your problem, thanks for reporting.

[mantognini]

You effectively get 800x600 -- in fact it is stretched to 800x600.

I'm not sure to get what you mean by it. 800x600 is stretched to 800x600? Put differently, do you use letterboxing or not? Does 800x600 windows fill the whole screen even if it's not a 4:3 monitor?

[eXpl0it3r]

@BlueCobold has provided example screenshots of the current behavior on OS X and as stated on that thread, I don't agree with the current implementation. Maybe I'm just biased by Windows, but when in fullscreen you really want the full screen.

And since the ratio adjustment isn't really the job of SFML, I'd say it should fully stretch. That would be the behavior on Windows.

But I'm also open for different perspective on that matter. For me it just feels wrong to have a small "window" in fullscreen. 😉

[mantognini]

Maybe I'm just biased by Windows, but when in fullscreen you really want the full screen.

No, you're probably right but since I've got barely no feedback (and I'm no Windows user) such issue can happen. 😉

As I said in my answer on that thread, maybe we should investigate the addition of another style flag (HardSwitchFullscreen). Even though I would personally discourage people of using it, I'm not against allowing people who love messing with the user desktop settings using it -- their customer will probably complain enough for me. :-P

On the soft switch mode: should it be scaled to fit the screen with the proper ratio (with letterboxing), or just stretched? I'd go for the first since the rendering is better.

[TankOs]

But it might not be what the developer or even the user wants. 800*600 is requested, how it's interpreted is then up to the developer. Let's not over-complicate this. ;-)

[TankOs]

Oh, a use-case that just came into my mind: Imagine you choose 800*600 because some projector you use doesn't support another mode, but you can easily scale it by pressing some buttons on the hardware. The effective resolution would be smaller if SFML did letterboxing. ;-) Yes, this is probably not a big deal, but it shows that SFML should not interfere, as stretching might indeed be intended.

[BlueCobold]

I agree with @eXpl0it3r here. If the developer/user decides to use a resolution for fullscreen mode, it is exactly what he should get - and it is what both user and developer would expect to happen anyway. If they want a 4:3 ratio on a 16:9 screen, so be it. If they want letterboxing to keep aspect-ratio, the developer can still do it himself. As you noticed with the beamer/projector, the natively requested resolution may have a pretty solid reason (apart from being the thing you asked the system for in the first place). If SFML doesn't change the physical resolution and only renders into a smaller render-target to then scale it to full screen size, the developer could do that himself already while he cannot do the other thing (native resolution instead of faked one) if forced by SFML.

[i8degrees]

For whatever it is worth … I agree with @eXpl0it3r and @BlueCobold on the resolution issue, but.. I also think that, as @mantognini stated, taking into consideration of supporting both methods is worth while. (I feel like both methods have their merits / use cases).

Cheers!

[BlueCobold]

Thing is that a developer, who's using SFML, can implement the soft-switch ("keep native and stretch it") himself easily for all platforms while he cannot add a hard-switch if SFML already does this soft-switch.

[TankOs]

@BlueCobold What are the issues with using a soft switch only?

[BlueCobold]

@TankOs

1. The device you might want to use to show the game on might not support the soft resolution (attached beamer)
2. FragmentShaders will see the native resolution while SFML-developers don't (no way the developer could fix problems related to that) - there already is a bugreport for OS X about this in the forum since OS X does some kind of windowed soft-resolution-scaling for "old" apps which don't support retina screens. With soft-switching, all OS will have this issue.
3. A developer can implement a soft-switch himself if SFML uses hard-switch, but the developer cannot implement a hard-switch if SFML uses a soft-switch
4. A soft-switch isn't what the developer asked for in the first place
5. Higher memory footprint, because internally large buffers are used always
6. More effort internally for SFML - you need to scale various event coordinates (Mouse in/out for example), shape-coordinates, (render)texture-coordinates, etc. Especially coordinates used by Sprites which are used with a RenderTexture will have totally screwed texture-coordinates/textureRects. I don't see how you want to get this thing handled at all, because there's no way to even detect that problem.
7. Screenshots being taken would be large instead of the resolution you wanted your app to have
8. Recorded videos would have large resolution instead of the resolution you wanted your app to have - this really impacts performance for screen-capturing and will have messed up quality - imo one of the worst things of all in this list.
9. Mouse-speed doesn't change as you would expect by using a window with lower resolution
10. It might interfer (and pretty surely will) with other stuff the developer might want to do by using OpenGL directly additional to SFML
11. What if the game/application wants to set a resolution higher than the one currently used be the user's desktop? It might be rare, but it surely could happen that the user is not using maximum resolution for his desktop. Then SFML would render in higher resolution and scale it down.
12. An application using 800x600 in windowed would behave differently than the same application using 800x00 fullscreen. Doesn't make any sense.
13. all the other crap I didn't even think of yet

1), 2), 6) and 8) being the worst ones in the list imo. 6) would totally screw up my own SFML-games. 7 and 8 would kill some planned features.

[TankOs]

@BlueCobold Very good points, thanks a bunch for that list. I don't get 1 however: Every resolution for soft-switching is supported, since only the view is scaled. You could even use a resolution of 123*456 if SFML would not prevent that in sf::VideoMode::isValid().

Due to the outlined points and generally giving the user the option makes me want to implement both techniques through different sf::Styles.

What do the other SFML team members say? It would affect all platforms.

[LaurentGomila]

In case it helps:

• SDL provides both modes.
• GLFW only does hard-switch (if I interpret their doc correctly)
• FreeGLUT seems to do both (regular fullscreen is a soft-switch, and what they call "Game mode" is a hard-switch)

[BlueCobold]

@TankOs The ability to use 123x456 is the only thing that is really really neat about soft-switch. Of course I believe both ways getting implemented would be a great thing, but if I had to chose one of the two, I'd always vote for hard-switch.

[eXpl0it3r]

Since with the current implementation fullscreen mode is broken completely and we've yet to come to a verdict on the whole fullscreen discussion, should I merge this in the meantime or do you, @TankOs, want to update it?

As for the discussion in general, let's keep it on the forum, either in the already on going discussion thread or if someone feels like it, they can open a new thread.

Only comment here further if you're actually referring to the PR.

[TankOs]

I will change this PR.

[binary1248]

Superseded by #825.