Release highlights:
-
New protocol implementations:
- content-type-v1 to tag surfaces with their content type (audio, video, game, etc).
- xwayland-shell-v1 to improve XWayland reliability.
- wp-fractional-scale-v1 to allow clients to submit buffers with a non-integer scale factor matching the output.
- tearing-control to allow clients to opt-in for tearing page-flips.
- security-context-v1 to identify clients running in sandboxes.
- cursor-shape-v1 for server-side cursor themes.
-
Introduce a new output layers API to leverage KMS planes.
-
Add a new renderer API with improved design and performance. Add an API to query the time taken to render.
-
Continued work on the Vulkan renderer: add more RGB formats, add YUV buffers, add interoperability with implicit synchronization instead of blocking.
-
Add support for the new wl_surface.preferred_buffer_{scale,transform} events.
-
Improved scene-graph, including support for linux-dmabuf feedback and clipping surfaces.
-
Improved wlr_cursor which now keeps track of the current cursor image.
-
Add an implementation of the wl_shm interface, replacing libwayland’s for improved reliability and performance.
-
The Wayland backend supports embedding a wlroots compositor inside an existing Wayland client.
-
wl_surface roles have been refactored.
- wp-fractional-scale-v1 to allow clients to submit buffers with a non-integer scale factor matching the output.
This hopefully means Sway and similar will support real fractional scaling for applications, not just the compositor fractional scaling we already have.
But I don’t know much about application support. Qt and Electron might support it; GTK 4 does not, possibly in a future version).
https://wayland.app/protocols/fractional-scale-v1
- tearing-control to allow clients to opt-in for tearing page-flips.
That’s great for those who need it. Anyone with a modern display should probably just use variable refresh rate (vrr), but even today some devices don’t support it. E.g. there’s been 240Hz laptops without vrr.
GTK 4 does not, possibly in a future version
That would be news to me. Has GTK finally managed to switch away from using actual real hardware pixels as its base unit for measurement?
I was sure I read that GTK wants to support true fractional scaling in GTK 5, but I can’t find a source to it. So it was probably just speculation. As far as I understand it, it would require big changes to GTK because everything is build with integer scaling in mind.
At least GTK 4 already has support for this fractional scaling protocol.
At least it does not look blurry with fractional scaling enabled, which is the biggest issue IMO. The current hacky way is not ideal I agree but at least it is functional
How would wlroots relate to the compositors such as KWin & GNOME Shell?
As pointed out, they don’t use it. However, there are loose plan for KWin to migrate to wlroots one day, and in fact a hostile fork exists that is exactly that (KWinFT). So a compositor can make use of wlroots to implement Wayland functionality, sway for example does exactly that, unsurprisingly since they’re sister projects by the same author.
It should be noted that libwayland (mentioned in the patch notes) also exist, and wlroot actually depends on it, so I guess libwayland is like the lower level stuff while wlroots saves you some work to integrate libwayland into your compositor; the motto is “Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway.”
Just a note, you said that libwayland is a higher level abstraction for libwayland.
libwayland is like the lower level stuff while libwayland saves you some work to integrate libwayland
Makes sense. You have to factor in libwayland though.
Thanks, I corrected it
As far as I know, it wouldn’t - I do not believe KWin nor Mutter is built on top of wlroots.
They are not
wlroots is a library that can be used to implement a compositor like KWin or mutter (GNOME). In practice wlroots is used in Sway, Hyprland, river, and more.
What wlroots-based compositors, KWin, and mutter share is that they implement a similar set of the display protocol Wayland. E.g. KWin and Sway implement the Wayland extension wlr_layer_shell
