Enable wayland by default

[kobutri]

What problem does this solve or what need does it fill?

Without enabling wayland bevy fails on systems that support wayland instead of falling back to x11, supported by xwayland.
This is because wgpu won't support x11 windows, when wayland is available on the system.

What solution would you like?

simply add "wayland" to the default features list.

What alternative(s) have you considered?

You can of course enable it manually, but many will forget and simply assume that wayland will be supported via xwayland.

[bjorn3]

It may also be nice to default to X11 (through Xwayland) on GNOME even when wayland is supported as GNOME refuses to properly implement some parts of wayland. For example they don't support server side decorations, so winit has to draw a rather ugly title bar itself instead.

[kobutri]

That would be a bad idea, because wgpu's gles backend will always use wayland when possible.
There is some discussion in winit and smithay_client_toolkit about adding libdecor support, for wayland, but for now we have to live with not the prettiest solution.

[bjorn3]

That would be a bad idea, because wgpu's gles backend will always use wayland when possible.

Then that is already a problem when wayland support is entirely disabled in winit. gfx-rs has logic to recreate the egl context when creating a surface for a different wayland window. I feel like this logic could be extended to recreating the egl context when creating a surface for an xcb or xlib window.

[heavyrain266]

GNOME will never add SSD because they asume that everyone uses GTK and prefered to implement titlebars with additional buttons, menus etc. as CSD thing...

About libdecor, I found out it as kind of library which isn't FFI friendly at all and getting it stabilized in SCTK may take months.

[mockersf]

What's the impact of enabling Wayland when running somewhere it's not available? Longer build times? Larger binaries?

[kirusfg]

Regarding the topic of SSD in Gtk: I have stumbled upon this issue in a Wayland compositor and there is a PR to fix this issue in Gtk by enabling optional SSD (judging from the description, that is what it does; correct me if I am wrong).

Might be of interest to you @heavyrain266.

[heavyrain266]

Regarding the topic of SSD in Gtk: I have stumbled upon this issue in a Wayland compositor and there is a PR to fix this issue in Gtk by enabling optional SSD (judging from the description, that is what it does; correct me if I am wrong).

Might be of interest to you @heavyrain266.

That doesn't fix absence of SSD in Mutter itself (GNOME's compositor) but adds option that you can disable GTK CSD in your Compositor to use your own SSD implementation.

[mcobzarenco]

What alternative(s) have you considered?
You can of course enable it manually, but many will forget and simply assume that wayland will be supported via xwayland.

For GNOME in Ubuntu, that would mean having to manually disable it to continue to use x11 (as this comment notes)?

[kobutri]

For GNOME in Ubuntu, that would mean having to manually disable it to continue to use x11 (as this comment notes)?

XWayland is currently broken for wgpu with gles as it is will create an Instance that is only compatible with wayland if wayland is available.

[keis]

Was scratching my head for a long while trying to figure out why the program was not exiting after closing the window. Enabling the wayland backend to stop relying to xwayland fixed the issue. Brief testing revealed no other issues.

[orowith2os]

For example they don't support server side decorations, so winit has to draw a rather ugly title bar itself instead.

There's nothing improper about this. It's perfectly valid in the spec to not support SSDs, and in some cases, expected, even. Plus, now we have libdecor and adwaita-sctk. There's not much need for SSDs, as now we can still get a similar end result.

In the process, this can make the creation of a compositor vastly simpler.

[Friz64]

I have worked hard on adding window shadows to sctk-adwaita, so the window decorations will, once this work is released and the dependencies are updated, fit right in on the GNOME desktop.

I can't live without wayland these days. The input-lag/latency is much lower and resizing windows is smooth as butter, compared to the stuttery mess that is X11, especially on high refresh rate screens.

[pkupper]

Another reason for wayland by default would be proper fractional scaling support. On my system (scale factor 1.5) applications running via XWayland applications are blurry due to being upscaled.

[Friz64]

What's the impact of enabling Wayland when running somewhere it's not available? Longer build times? Larger binaries?

About a 5% difference in compile time. This is 33.4s -> 35.2s on my beefy Ryzen 9 7900X machine, as shown below. Of course, on slower computers, this will be more noticeable.

$ hyperfine --prepare 'cargo clean' 'cargo build --release --example 3d_scene' 'cargo build --release --example 3d_scene --features wayland'
Benchmark 1: cargo build --release --example 3d_scene
  Time (mean ± σ):     33.408 s ±  0.281 s    [User: 646.068 s, System: 20.888 s]
  Range (min … max):   33.037 s … 33.850 s    10 runs
 
Benchmark 2: cargo build --release --example 3d_scene --features wayland
  Time (mean ± σ):     35.205 s ±  0.157 s    [User: 705.365 s, System: 24.624 s]
  Range (min … max):   34.995 s … 35.429 s    10 runs
 
Summary
  cargo build --release --example 3d_scene ran
    1.05 ± 0.01 times faster than cargo build --release --example 3d_scene --features wayland

The binary size for the 3d_scene example went from 61M to 64M, which is also about a 5% increase.