So, I'm moving away from SFML due to Wayland support

[mort]

I started working on a game some months ago, and decided to use SFML. I love it so far, the API is nice, it's fast, it's native to C++. However, I've decided to move to SDL due to the lack of Wayland support, and I figured it might be valuable to outline some of my reasons why. The topic of Wayland support has been discussed before, and the conclusion has mostly been that it's not necessary, and that XWayland works well enough.

Well, here are the reasons I have personally decided that relying on XWayland isn't good enough for my game;

• XWayland windows, on my compositor (Sway), don't support HiDPI. They're drawn at 1x resolution, then upscaled. My game uses pixel-art-y graphics, and paradoxically, upscaling pixel art doesn't work very well, because it looks blurry.
• Some desktops, like GNOME, have worked really hard to make XWayland windows look crips even on HiDPI screens. However, if you have one 2x screen and one 1x screen, the XWayland application will look fine on the primary screen, and either tiny or way too big on the secondary.
• The way XWayland forwards events to the X application results in an application which feels wrong. Particularly, touchpad scrolling is really rough.

I recently integrated imgui (via imgui-sfml) into the game, and it really made those issues clear; the text looks blurry, touchpad scrolling feels weird, etc.

So, I kind of had three options:

• Live with the fact that my game feels like a second-class citizen on my own computer
• Patch SFML to add Wayland support
• Move to SDL

I seriously considered option 2, but since I'm working on this game next to work and studies, I would never get anywhere if I first had to patch SFML. Option 1 is obviously undesirable, so that leaves option 3.

I'm not making this post to try to guilt anyone into adding Wayland support to SFML. Nobody is owed Wayland support, XWayland works "well enough", and there are probably other tasks which one could reasonably judge to be higher priority. However, I just want to chime in and point out that it's not really the case that X11 still has first-class support. XWayland is more of a transitional kludge to keep old software working rather than a fully supported option. That's probably not going to change any time soon, and X11-only software is going to feel more and more out of place as the Linux desktop (slowly) moves toward Wayland.

[binary1248]

The linked forum thread is from 2013 and the issue is from 2016 (and didn't really discuss any concrete benefits of supporting Wayland other than "it's the new thing").

We're in the latter half of 2019 now, 6 and a half years since the original thread was written. A lot has happened since then. Many mainstream distros have decided to make Wayland the default session, the latest being Debian which is a pretty significant milestone and a testament to the stability and support it has gained over the years.

I remember experimenting with Wayland back then as well. It wasn't pretty, and still really experimental. If something went wrong with your exotic setup you were pretty much on your own. It wasn't a very nice environment to develop in. This coupled with the fact that not many "casual" users would even make use of potential Wayland support on their daily drivers and the fact that Wayland didn't provide any tangible advantages over X11 back then lead to Laurent deciding not to dedicate developer time to supporting the platform.

What hasn't changed since then is that SFML is still constrained by developer time. In contrast to other libraries, none of the SFML's contributors are compensated in any way for working on SFML and it's development isn't endorsed by any organization either. Just as back then, we need to prioritize features we feel provide a meaningful benefit to the library, as opposed to features that are just "nice to have" or "would be cool".

Considering that Wayland today has matured a lot since 2013 and development should no longer be as painful as it was back then, I wouldn't say it is off the table that support for it in SFML will come one day. The question is who will implement it. Since this is a pure backend enhancement with no public API changes, the necessary discussion should be kept to a minimum. I might have a look when I have a bigger chunk of free time on my hands.

[Laurent]

The question then is: do we still need to support X11? Are there X11 emulation layers that work on top of Wayland (like XWayland, but the other way round)? Or is Wayland so widely adopted now that nobody relies on X11 anymore?

[mort]

The linked forum thread is from 2013 and the issue is from 2016 (and didn't really discuss any concrete benefits of supporting Wayland other than "it's the new thing").

Yeah, I should've mentioned something about that; it was certainly a good decision, especially in 2013, to focus development on other things. However, I haven't seen any discussion more recent than the 2016 issue, and as you point out, they didn't actually mention reasons for supporting Wayland other than that it's new, so I figured it was time for a new discussion.

The question then is: do we still need to support X11? Are there X11 emulation layers that work on top of Wayland (like XWayland, but the other way round)? Or is Wayland so widely adopted now that nobody relies on X11 anymore?

X11 will certainly be relevant for a long time still. Even when shipping Wayland by default, distros will continue to have X11 as a fallback for the foreseeable future, and as long as NVidia refuses to play ball, people who need to use their proprietary drivers will use X11 (there is some progress on getting support for their weird non-standard stuff into GNOME and KDE, but the wlroots project has essentially said that they won't duplicate all their hardware acceleration effort just because of NVidia).

The "proper" way to do Wayland support seems to be to detect whether the user is on X11 or Wayland based on environment variables at runtime, at least that's what Qt and GTK does. It can't be purely a compile-time option.

I'm not aware of any compatibility layer for running Wayland-only applications on X11, but it should be possible to make one. A lot of the existing compositors can already run as an X11 window within an X session, so making a reverse XWayland (WaylandX?) would "just" involve taking a compositor (say, wlroots) and make it ensure that the wayland window always fills the entire surface of the compositor (plus making the X11 window's title bar match the Wayland window's title bar and such).

I suspect that wouldn't be as good as the current native X11 backend though, and creating and maintaining that compatibility layer would probably be more work than maintaining two separate windowing system backends for unix.

[markand]

I think the best thing to do here is to implement a secondary wayland backend and conditionally use the appropriate one depending on the environment variables. SDL, GTK do this (probably by checking DISPLAY). Then after some years we could drop X11 backend completely.

I don't know much wayland internals yet to provide support for it though SDL could be a good start I think?

That said, X11 must die especially since running X11 apps under wayland sessions is sometimes problematic.