Speaking of Wayland, one of the most important parts of the transition is Xwayland, which makes sure legacy X applications not yet capable of running under a modern graphics stack can continue to function. Xwayland applications have had this weird visual glitch during resize operations, however, where the opposite side of the window would expand and contract while resizing. KDE developer Vlad Zahorodnii wanted to fix this, and he wrote a very detailed article explaining why, exactly, this bug happens, which takes you deep into the weeds of X and Wayland.
Window resizing in X would be a glitchy mess, if it wasn’t for the X11 protocol to synchronize window repaints during interactive resize, which ensures that the window resize and the application repainting its window contents remain synchronised. This protocol is supported by Kwin and GNOME’s Mutter, so what’s the problem here? Shouldn’t everything just work?
KWin supports the basic frame synchronization protocol, so there should be no visual glitches when resizing X11 windows in the Plasma Wayland session, right? At quick glance, yes, but we forget about the most important detail: Wayland compositors don’t use
↫ Vlad ZahorodniiXCompositeNameWindowPixmap()
orxcb_composite_name_window_pixmap()
to grab the contents of X11 windows, instead they rely on Xwayland attaching graphics buffers towl_surface
objects, so there is no strict order between the Wayland compositor receiving an XSync request acknowledgement and graphics buffers for the new window size.
Basically, the goal of the fix is to make sure these steps are also synchronised when using Xwayland, and that’s exactly what Zahorodnii has achieved. This makes the resizing X windows under Xwayland look normal and without weird visual glitches, which is a massive improvement to the overall experience of using a Wayland desktop with a few stray X applications. Thanks to this fix, which was made possible with help from Wayland developers, Kwin is now one of the few compositors that correctly synchronises X windows running under Wayland.
KDE has been doing an amazing job moving from X to Wayland, and I don’t think there’s anyone else who has managed to make the transition quite as painless. Not only do KDE developers focus on difficult bugs like this one that many others would just shrug off as acceptable jank, they also made things like the Wayland to X11 Video Bridge, a desktop-agnostic tool to allow things like screen sharing in Teams, Discord, Slack, etc. to work properly on Wayland.
On a side note, from time to time I try Gnome3, and I really do not understand what the f*ck they tried to did. What a disaster it is from an UX point of view. Crazy bad.
From time to time you load a GNOME release last updated in 2020 and complain about it?
How odd…
Gnome 3 was released in 2011. One hopes it gets improved over time. What is odd is that you don’t understand such a simple concept.
I think what @JesseWagner meant was that GNOME changed their version numbering a while back and they are currently on GNOME 47 (which would be 3.47 under the old versioning system that is no longer in use).
Of course I meant gnome current. 3 as in vs 2.
Either way saying GNOME 3 sure sounds like you have not checked it recently. I’m not making an argument for it, but I’m sensitive to complaining about the work of others. Best reserved for your own alternate work, patch set, or home bathroom.
The article is about KDE, so why the GNOME hatred?
I keep KDE around mostly so other people can use my computer, and I like a number of it’s apps. It’s a fine desktop for people who miss OSX/Windows; I’m not one of those people anymore. Maybe if I could turn off every single animation and effect, but at that point I know I’m trying too hard and just switch to something a little more intuitive to me like i3.
Next you’ll tell us VIM is an IDE!! (It kind of is, or can be anyway)