I fear you are right. While there might be commits in the Wayland repos, featurewise progress has ceased. Waylands broken architecture has made progress hard to impossible. Porting of popular window managers is extremely slow since there is just no thought given to X compatibility. Input handling by each application on its own is insane and broken. Feature-consistency across compositors on things like screenshots is a pipe-dream. A promised easy ssh -X replacement doesn't work right after a decade.
Waylands broken architecture makes progress slow through unnecessary duplication, incompatibility and the lack of a smooth migration for many software packages (usually it's rewrite-time). Wayland should be abandoned and the design redone.
The design overview slides are their own critique: Wayland does almost nothing besides render buffer handling. Input? Applications job. Window decorations? Compositors job. Application talking to the Compositor? Somebody elses job. Clipboard? Maybe compositor or toolkit. Screenshots and remoting? Somebody elses job, but only after Wayland has bored the appropriate holes in its security model. This all leads to a ton of incompatibilities between compositors, toolkits and applications. And beyond Gnome, the full "featureset" is still not implemented, where "featureset" is barely adequate as an X11 replacement.
But the buffer handling is great, no more flickering...
... so long as you don't care about latency and don't mind a $3000 top of the line 64 core desktop feeling slightly slower than a machine from 20 years ago.
This depends on the user. Personally I never minded the extra frame of latency.
And some of the newer Gnome desktops have even removed that, thanks to some tricky work by one guy, as I understand it.
I may have misunderstood the explanation but it seems to involve some nice timing getting all of the application buffers swapped just before the main GPU screen buffer swap. This gives applications long enough to draw updates, for the most part, and gets all updates into the next screen buffer update instead of the update after that.
As I understand it the extra latency is relatively hardware independent, and caused by extra whole frames of delay from additional compositing layers. I expect an anaemic SOC to be slow, it's less fun when extremely high end machines are also slow.
Every time I pull a old system out of mothball and start it up I'm disappointed at how much less responsive the feel is of modern systems sitting right next to them.
This comment is mostly correct (as a daily Wayland user), with a few exceptions.
> Wayland does almost nothing besides render buffer handling. Input? Applications job.
Applications don't do more work to handle input on Wayland as opposed to e.g. X11. It's still event-based, and the compositor feeds input events to applications that can process them as normal. Keyboard, mouse and touch input are part of the core Wayland protocol, and tablet input is part of an extension that all major compositors fully support.
> Window decorations? Compositors job.
Kind of, it's the job of the application (client-side decorations) or compositor (server-side decorations). The compositor can choose which to use. CSDs give more custom look-and-feels to applications that have them (think Firefox or Chrome); SSDs provide consistent looks across all apps. GNOME only supports CSDs, but is an exception in that regard.
Waylands broken architecture makes progress slow through unnecessary duplication, incompatibility and the lack of a smooth migration for many software packages (usually it's rewrite-time). Wayland should be abandoned and the design redone.