4 ms·
> Wayland is really slow. I think you don't mean that the Wayland protocol forces slowness but that the compositor you used was slow. The one I use is fast. >
by solarkraft 6y ago
> Wayland is really slow.
I think you don't mean that the Wayland protocol forces slowness but that the compositor you used was slow. The one I use is fast.
> And if you don't like the window decorations (say, they take up too much screen space) your choices are suck it up, or if you're lucky and willing to spend a bunch of time reconfigure every different toolkit your apps use.
No, there are protocols to negotiate whether an app has server side decoration or not and the compositor has the last say.
> basic stuff that worked fine on X11 doesn't work on wayland in the name of "security"
On only the core Wayland protocols you're absolutely correct, you can't even implement desktop shells with those. This means there must be extensions and there are 3 different classes: KDE, GNOME, wlroots, with tools for and incompatibility between each. The wlroots extensions are designed to be accepted into the standard and for wider Wayland acceptance they probably should be.
Screen sharing is still a particular issue that we are starting to see solved with the advent of Pipewire.
Wayland desktops are definitely usable. I've been happy with a wlroots based one (Wayfire) for a few months and KDE before that (from what I see GNOME has been perfect for a while).
One of the last standing real issues I'm facing is kerfuffle with Nvidia drivers, especially the ones paired with Intel GPUs, but I think (surprisingly) Nvidia are actually working on fixing that.
- mort96 6y ago> No, there are protocols to negotiate whether an app has server side decoration or not and the compositor has the last say. The compositor can implement that protocol and just respond with "this compositor doesn't support SSDs". GNOME does this, so all toolkits must use CSDs if they wanna work on the most popular Wayland compositor. Incidentally, that's hell for all the simple libraries out there which just exist to get a GL window on the screen. GLFW, GLEW, SDL, etc. all have to implement CSDs now if they wanna work with Wayland. It also means that it's no longer feasible to just make a Linux application which uses the windowing system directly; everything must use a huge toolkit now. EDIT: To clarify, I don't think this is an issue with Wayland, but with GNOME. There's no reason it couldn't have supported SSDs like every other Wayland compositor. But as it stands, it hurts the Wayland ecosystem.
- cycloptic 6y agoGLFW and SDL are looking at using libdecoration to draw CSDs. Yes it's an additional dependency but most applications won't need to worry about it unless they need it. The way GNOME is built it's not really possible architecturally for them to support SSDs in Wayland. Maybe that will change if they ever get around to redesigning mutter and gnome-shell, but I wouldn't wait for it.
- mort96 6y agoI've seen libdecoration, and yeah, that seems like their intended solution to this. It doesn't seem like a terrible solution, but last time I looked at it at least, libdecoration was a long way off being production ready, and GNOME with Wayland is shipping _right now_ and must be supported.
- cycloptic 6y agoYou can use a library like that or you can draw your own decorations. There unfortunately is no other option. I don't see it as being likely that GNOME will support SSD any time soon, it just isn't designed for that.
- mort96 6y agoI know, and that's kind of what I'm complaining about. There's no reason it couldn't support SSDs.
- cycloptic 6y agoI was trying to be clear here: There is a reason and it's that it's not really possible architecturally for them to support SSDs in Wayland; doing so would require a redesign of significant parts of the compositor's code. I'm sorry if that was misunderstood. If you're trying to say they should have anticipated this and made a different architectural decision years ago, maybe that's true, but that also offers no practical solution to the applications that need to support it right now.
- bigbubba 6y ago> The [compositor] I use is fast. [...] I've been happy with a wlroots based one (Wayfire) for a few months wlroots performed very poorly on my i5-3427U with 4000 series iGPU. Very poorly. I ended up using neither X nor Wayland and instead having mpv render straight to the frame buffer (--vo=gpu --gpu-context=drm)
- emersion 6y agoI'm a wlroots developer, and I'm using an old Sandybridge mobile i5 CPU daily. So I'm pretty surprised about this. I'd be interested in a bug report if you were to try again.
- swiley 6y agoI'll agree with this post. Wayland is not pleasant on my core i5 machine either. I should point out that the GPU it has is very weak, I don't know what it is but most 3d games are unplayable. X.org, Firefox, and Xterm all work very well on it though. As do other apps like gschem and openscad.
- emersion 6y ago"Wayland" is just the protocol, can you give more details about your setup? For instance, GNOME is more heavyweight than say Sway (and gives a more feature-ful and eye-candy user experience in return).