Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xfwl4 – The Roadmap for a Xfce Wayland Compositor

alexxcons.github.io

Post reply on HN
Print view View original

171–180 of 339 posts

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#171

Post by rabf »

jeroenhd wrote: post #161
drob518 wrote: post #124

Earlier quoted context omitted.

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/10…

CRT screens did 75Hz/85Hz/100Hz quite well, but rendered only one pixel/dot at a time. This is in no way equivalent to 60Hz on a flat panel!

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#172

Post by layer8 »

drob518 wrote: post #145
layer8 wrote: post #132

Earlier quoted context omitted.

I agree. Keyboard-action-to-result-on-screen latency is much more important, and we are typically way above 17 ms for that.

Yep, agreed, though it’s not just keyboard to screen. It’s also mouse click to screen. Really, any event to screen.

Initially I wrote “input device”, but since mouse movements aren’t generally a problem, I narrowed it to “keyboard”. ;) Mouse clicks definitely fall into the same category, though.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#173

Post by joe_mamba »

pjmlp wrote: post #110
amazari wrote: post #98

Earlier quoted context omitted.

You know that all the Wayland primitives, event handling and drawing in gnome-shell are handled in C/native code through Mutter, right ? The JavaScript in gnome-shell is the cherry on top for scripting, similar to C#/Lua (or any GCed language) in game engines, elisp in Emacs, event JS in QtQuick/QML. It is not the performance bottleneck people seem to believe.

I can dig out the old GNOME tickets and related blog posts... Implementation matters, including proper use of JIT/AOT toolchains.

>I can dig out the old GNOME tickets and related blog posts...

That's the easiest way you can win any argument on gnome. You're going straight for the nuclear option.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#174

Post by elektronika »

coldpie wrote: post #163
elektronika wrote: post #146

Earlier quoted context omitted.

> 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.

My point is that using C FFI is "the things the compiler would normally forbid you from doing" so if that's a major portion of your program then you're better off picking a different language. I don't dislike rust, but it's not the right tool for any project that relies heavily on C libraries.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#175

Post by dTal »

PaulDavisThe1st wrote: post #148
yason wrote: post #126

Earlier quoted context omitted.

Because Wayland only does essential low-level stuff such as display and graphics it forced people to start coming up with a common Linux desktop (programming) interface out of nowhere to basically glue everything together and make programs at least interoperate. Such an effort to rethink Linux desktop alone could've been a major project on its own but as having something was necessitated by Wayland all of it has beco…

Nobody has a user-space stick big enough to force things in the Linux world. When Apple dropped the old audio APIs of classic macOS and introduced CoreAudio, they pissed off a lot of developers, but those developers had no choice. In the GUI realm, they only deprecated HIKit for a decade or two before removing it (if they've even done that), but they made it very clear that CoreFoo was the API you should be using and…

systemd comes close, and can be viewed as an attempt to create such a stick...

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#177

Post by throw0101a »

gf000 wrote: post #160
throw0101a wrote: post #78

Earlier quoted context omitted.

> It depends on what you mean by send. Currently I can: $ ssh -X somehost xeyes and get a window on macOS.

For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it. X's network transparency was made at a time when we drawn two lines as UI, and for that it works very well. But today even your Todo app has a bunch of icons that are just bitmaps to X, and we can transfer those via much better means (that should probably not…

> For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it.

I used run and use diskless SparcStation 5s with remote X on 10BASE2 network with the binaries running on Sun E3500s: it worked well enough for non-video web sites running Netscape 3.x. Also Matlab, Octave, Emacs, Vi(m), etc.

I've used it to run backup application GUIs when I was still on DSL (100Mbps fibre at home, so doubt that bandwidth (or even latency) is worse.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#178

Post by mikkupikku »

Fiveplus wrote: post #28

>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…

Compositor overhead even with cheapo Intel laptop graphics is basically a non-issue these days. The people still rocking their 20 year old thinkpads might want to choose something else, but besides that kind of user I don't think it's worth worrying too much about.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#179

Post by wtallis »

drob518 wrote: post #143
elektronika wrote: post #134

Earlier quoted context omitted.

> how many people were complaining about that over the last decade? Quite a few. These articles tend to make the rounds when it comes up: https://danluu.com/input-lag/ https://lwn.net/Articles/751763/ Perception varies from person to person, but going from my 144hz monitor to my old 60hz work laptop is so noticeable to me that I switched it from a composited wayland DE to an X11 WM.

Input lag is not the same as refresh rate. 60 Hz is 16.7 ms per frame. If it takes a long time for input to appear on screen it’s because of the layers and layers of bloat we have in our UI systems.

Refresh rate directly affects one of the components of total input lag, and increasing refresh rate is one of the most straightforward ways for an end user to chip away at that input lag problem.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#180

Post by jauntywundrkind »

LeFantome wrote: post #108

In my view, this project itself shows some of the reasons why Wayland is the right path forward. On X, we had Xorg and that is it. But at least Xorg did a lot of the work for you. On Wayland, you in theory have to do a lot more of the work yourself when you build a compositor. But what we are seeing is libraries emerge that do this for you (wlroots, Smithay, Louvre, aquamarine, SWC, etc). So we have this one man proj…

The other key element with Wayland is that the kernel does a ton of the work for you. There s GEM buffer management and DMA-BUF to manage and move around video & regular memory, there's kernel mode setting, there's incredibly good mesa drivers.

X didn't have any of that to build from. It basically was a second kernel, was the OS that dealt with the video card atop the OS actual. It talked to the PCI device & did everything.

Part of the glory of Wayland is that we have fantastic really good OS abstractions & drivers. When we go to make a display server, we start at such a different level now. Trying to layer X's abstractions atop is messy & ugly & painful, because it mostly inhibits devs from being able to use the hardware in neat efficient clean direct modern ways. You have to write an X extension that coexists with a patchwork of other extensions that slots into the X way, that can figure out how to leverage the hardware. With Wayland, most compositors just use the kernel objects. There's much less intermediary, much less cruft, much less wild indirection & accretion to cut a path for.

And as you beautifully state, competing libraries can decide what abstractions & techniques work for them. There's an ecosystem of ideas, a flux to optimize hone & improve, on a variety of different dimensions. The Bazaar free to find its way vs the one giant ancient Cathedral. It's just so so so good we're finally not all trapped inside.

Tl;dr: Wayland has a much higher level that it can start from. And trying to use gpu's & hardware well in X was a nightmare because X has a sea of abstractions - extensions that you had to target & develop around, making development in X a worst of both worlds low level but having to cope with a so many high level constructs you had to navigate through.

Post reply on HN