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.
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.
https://www.phoronix.com/news/GTK-4.11.1
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