Live data from Hacker News

Xfwl4 – The Roadmap for a Xfce Wayland Compositor

alexxcons.github.io

161–170 of 339 posts

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#161
post #100

Earlier quoted context omitted.

> Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland? I think this is ultimately correct. The compositor will have to render a frame at some point after the VBlank signal, and it will need to render with it the buffers on-screen as of that point, which will be from whateve…

Love your post. So, don’t take this as disagreement. I’m always a little bewildered by frame rate discussions. Yes, I understand that more is better, but for non-gaming apps (e.g. “productivity” apps), do we really need much more than 60 Hz? Yes, you can get smoother fast scrolling with higher frame rate at 120 Hz or more, but how many people were complaining about that over the last decade?

I enjoy working on my computer more at 144Hz than 60Hz. Even on my phone, the switch from 60Hz to a higher frame rate is quite obvious. It makes the entire system feel more responsive and less glitchy. VRR also helps a lot in cases where the system is under load.

60Hz is actually a downgrade from what people were used to. Sure, games and such struggled to get that kind of performance, but CRT screens did 75Hz/85Hz/100Hz quite well (perhaps at lower resolutions, because full-res 1200p sometimes made text difficult to read on a 21 inch CRT, with little benefit from the added smoothness as CRTs have a natural fuzzy edge around their straight lines anyway).

There's nothing about programming or word processing that requires more than maybe 5 or 6 fps (very few people type more than 300 characters per minute anyway) but I feel much better working on a 60 fps screen than I do a 30 fps one.

Everyone has different preferences, though. You can extend your laptop's battery life by quite a bit by reducing the refresh rate to 30Hz. If you're someone who doesn't really mind the frame rate of their computer, it may be worth trying!

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#162
post #3

I hope that XFCE remains a solid lightweight desktop option. I've become a huge fan of KDE over the past couple of years, but it certainly isn't what you would consider lightweight or minimal. Personally, I'm a big proponent of Wayland and not big Rust detractor, so I don't see any problem with this. I do, however, wonder how many long-time XFCE fans and the folks who donated the money funding this will feel about it…

My watch from 8 years ago runs Wayland. Nothing written in Rust as far as I can tell, though.

With that knowledge, I'm certain that XFCE will remain lightweight. It can be done, so I feel confident that the XFCE folks will get it done.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#163

Earlier quoted context omitted.

This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. Keeping the whole “it’s funded by the Government/Google etc” nonsense aside: I personally wish that at least a feeble attempt would be made to actually use the FFI capabilities that Rust and its ecosystem has before folks form an opinion. Personally - and I’m not ashamed to state that I’m an early adopter of…

> This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. I have done it and it left a bad taste in my mouth. Once you're doing interop with C you're just writing C with Rust syntax topped off with a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer. It's unergonomic and you lose the differentiating features of Rust. Writing safe bindings i…

> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer

That's bizarrely emotional. It's a language feature that allows you to do things the compiler would normally forbid you from doing. It's there because it's sometimes necessary or expedient to do those things.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#164
post #154

Earlier quoted context omitted.

Systemd was easy for me. All things worked in transition and have the big advantage that don't need shell scripts for create services. Wayland..., is slow, buggy, applications close without reason...

How on earth would Wayland be slow? Like it's literally an IPC on top of the lowest level Linux kernel API (DRM), displaying buffers. It was partially made for car infotainment systems that are knowingly weak hardware.

Fully-featured DEs like Gnome and KDE work a lot worse when doing everything in software rendering. If you're working on a device with subpar/nonexistent GPU driver support (i.e. Nvidia hardware for years on end), the experience is absolutely awful.

Nvidia's driver do something weird on Wayland when my laptop is connected to HDMI, probably something funky with the iGPUdGPU communication. Everything works, but at the whims of Nvidia an update reduces the maximum FPS I can achieve over HDMI to about 30-45fps. Jittery and painful, even on a monitor that supposedly supports VRR.

That's not really Wayland's fault of course, but in the same way Linux is broken because Photoshop doesn't work on it, Wayland is broken for many users because their desktop is weird on it.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#165

Isn't the switch from X11 to Wayland the most painful switch that happened in the linux world ? Even going from python 2 to 3 was not as bad

Just wait. In 8 years, Wayland will be as old as X11 was when Wayland was created. Then we'll make Wayland 2.

X11 was basically used everywhere when it was released

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#166
post #100

>The goal is, that xfwl4 will offer the same functionality and behavior as xfwm4 does... I wonder how strictly they interpret behavior here given the architectural divergence? As an example, focus-stealing prevention. In xfwm4 (and x11 generally), this requires complex heuristics and timestamp checks because x11 clients are powerful and can aggressively grab focus. In wayland, the compositor is the sole arbiter of fo…

> Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland? I think this is ultimately correct. The compositor will have to render a frame at some point after the VBlank signal, and it will need to render with it the buffers on-screen as of that point, which will be from whateve…

I couldn't find ready stats on what percentage of displays are 60 hz but outside of gaming and high end machines I suspect 60 hz is still the majority of of machines used by actual users meaning we should evaluate the latency as it is observed by most users.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#167

Does Wayland work on non-Linux systems (e.g. *BSD)? If an application is written for Wayland, is there a way to send its windows to (e.g.) my Mac, like I can with X11 to XQuartz?

Microsoft's WSL2 GUI integration works based on Wayland (and XWayland): https://github.com/microsoft/wslg

Rather than going fully protocol-based (like Waypipe), they used Weston to render to RDP. Using RDP's "remote apps" functionality, practically any platform can render the windows. I think it's a pretty clever solution, one perhaps even better than plain X11 forwarding (which breaks all kinds of things like GPU acceleration).

I don't know if anyone has messed with this enough to get it to work like plain old RemoteApps for macOS/BSD/Windows/Linux, but the technology itself is clearly ready for it.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#169
post #152
post #144

Earlier quoted context omitted.

What do you mean nobody wants to improve X11? There were developers with dozens of open merge requests with numerous improvements to X11 that were being actively ignored/held back by IBM/Red Hat because they wanted Wayland, their corporate project, to succeed instead.

Reviewing PRs and merging them requires great effort, especially in case of a non-trivial behemoth like X. Surely if all these merge requests were of huge value, someone could have forked the project and be very happy with all the changes, right? Not having enough maintainers, and some design issues that can't be solved are both reasons why X was left largely unmaintained.

> Surely if all these merge requests were of huge value

There were a lot of MRs with valuable changes however Red Hat wanted certain features to be exclusive to Wayland to make the alternative more appealing to people so they actively blocked these MRs from progressing.

> someone could have forked the project and be very happy with all the changes, right?

That's precisely what happened, one of the biggest contributors and maintainers got bullied by Red Hat from the project for trying to make X11 work and decided to create X11Libre (https://github.com/X11Libre/xserver) which is now getting all these fancy features that previously were not possible to get into X11 due to Red Hat actively sabotaging the project in their attempt to turn Linux into their own corporate equivalent of Windows/macOS.

Post reply on HN