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

141–150 of 339 posts

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#141

Post by drob518 »

bee_rider wrote: post #133
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?

If our mouse cursors are going to have half a frame of latency, I guess we will need 60Hz or 120Hz desktops, or whatever. I dunno. It does seem a bit odd, because who was thinking about the framerates of, like, desktops running productivity software, for the last couple decades? I guess I assumed this would never be a problem.

Mouse being jumpy shouldn’t be related to refresh rate. The mouse driver and windowing system should keep track of the mouse position regardless of the video frame rate. Yes, the mouse may jump more per frame with a lower frame rate, but that should only be happening when you move the mouse a long distance quickly. Typically, when you do that, you’re not looking at the mouse itself but at the target. Then, once you’re near it, you slow down the movement and use fine motor skills to move it onto the target. That’s typically much slower and frame rate won’t matter much because the motion is so much smaller.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#142

Post by [deleted] »

bee_rider wrote: post #25
ok123456 wrote: post #20

Earlier quoted context omitted.

Why does Wayland "feel like the future?" It feels like a regression to me and a lot of other people who have run into serious usability problems. At best, it seems like a huge diversion of time and resources, given that we already had a working GUI. (Maybe that was the intention.) The arguments for it have boiled down to "yuck code older than me" from supposed professionals employed by commercial Linux vendors to sup…

Because X is not getting much development at this point (personally I still use i3, haven’t switched to Sway, the present works fine for me).

[deleted]

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#143

Post by drob518 »

elektronika wrote: post #134
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?

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

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#144

Post by diath »

PunchyHamster wrote: post #64
ok123456 wrote: post #20

Earlier quoted context omitted.

Why does Wayland "feel like the future?" It feels like a regression to me and a lot of other people who have run into serious usability problems. At best, it seems like a huge diversion of time and resources, given that we already had a working GUI. (Maybe that was the intention.) The arguments for it have boiled down to "yuck code older than me" from supposed professionals employed by commercial Linux vendors to sup…

It's mostly coz nobody really wants to improve X11. I don't think there is many wayland features that would be impossible to implement in X11 it's just nobody wants to dig into crusty codebase to do it. And sadly wayland decided to just not learn any lessons from X11 and it shows.

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.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#145

Post by drob518 »

layer8 wrote: post #132
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 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.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#146

Post by elektronika »

fork-bomber wrote: post #89
duped wrote: post #67

Earlier quoted context omitted.

There really isn't a "massive barrier" to FFI. Autogenerate the C bindings and you're done. You don't have to wrap it in a safe abstraction, and imo you shouldn't.

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 is painful, and using community written ones tends to pull in dozens of dependencies. If you're interfacing a C library and want some extra features there are many languages that care far more about the developer experience than Rust.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#147

Post by jchw »

bee_rider wrote: post #133
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?

If our mouse cursors are going to have half a frame of latency, I guess we will need 60Hz or 120Hz desktops, or whatever. I dunno. It does seem a bit odd, because who was thinking about the framerates of, like, desktops running productivity software, for the last couple decades? I guess I assumed this would never be a problem.

Mouse cursor latency and window compositing latency are two separate things. I probably did not do a good enough job conveying this. In a typical Linux setup, the mouse cursor gets its own DRM plane, so it will be rendered on top of the desktop during scanout right as the video output goes to the screen.

There are two things that typically impact mouse cursor latency, especially with regards to Wayland:

- Software-rendering, which is sometimes used if hardware cursors are unavailable or buggy for driver/GPU reasons. In this case the cursor will be rendered onto the composited desktop frame and thus suffer compositor latency, which is tied to refresh rate.

- Atomic DRM commits. Using atomic DRM commits, even the hardware-rendered cursors can suffer additional latency. In this case, the added latency is not necessarily tied to frame times or refresh rates. Instead, its tied to when during the refresh cycle the atomic commit is sent; specifically, how close to the deadline. I think in most cases we're talking a couple milliseconds of latency. It has been measured before, but I cannot find the source.

Wayland compositors tend to use atomic DRM commits, hence a slightly more laggy mouse cursor. I honestly couldn't tell you if there is a specific reason why they must use atomic DRM, because I don't have knowledge that runs that deep, only that they seem to.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#148

Post by PaulDavisThe1st »

yason wrote: post #126
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…

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

In Linux-land, nobody has that authority. Nobody can come up with an equivalent to Core* for Linux and enforce its use. Consequently, you're going to continue to see the Qt/GTK/* splits, where the only commonality is at the lowest level of the window system (though, to Qt's credit, optionally also the event loop).

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#149

Post by gf000 »

_fat_santa wrote: post #91
0x1ch wrote: post #84

Earlier quoted context omitted.

I've been on and off linux desktops since the advent of Wayland. Unsure of the actual issues people run into at this point outside of very niche workflows or applications, to which, there are X11 fallbacks for. Also, by "commercial linux vendors", you do realize Wayland is directly supported (afaik, correct me if wrong) by the largest commercial linux contributors, Red Hat, Canoncial. They're not simply 'vendors'.

> Unsure of the actual issues people run into at this point outside of very niche workflows or applications, to which, there are X11 fallbacks for. I don't know if others have experienced this but the biggest bug I see in Wayland right now is sometimes on an external monitor after waking the computer, a full-screen electron window will crash the display (ie the display disconnects). I can usually fix this by switchin…

Is it gnome or kde or what?

That's like saying "the website doesn't work", without saying what browser you are using.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#150

Post by gryn »

simoncion wrote: post #53
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…

> ...or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland? I think I know what "frame perfect" means, and I'm pretty sure that you've been able to get that for ages on X11... at least with AMD/ATi hardware. Enable (or have your distro enable) the TearFree option, and there you go. I read somewhere that TearFree is triple buffering, so -if true- it's my (perhaps mistak…

only on the primary display. once you had more than one display there were only workarounds.
Post reply on HN