Messages

1

Feature requests / Re: So, I'm moving away from SFML due to Wayland support

« on: October 25, 2019, 01:13:07 pm »

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.

2

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

« on: October 25, 2019, 01:18:15 am »

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.