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

241–250 of 339 posts

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#241

Post by argulane »

kelnos wrote: post #209
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…

(xfwl4 author here.) > I wonder how strictly they interpret behavior here given the architectural divergence? It's right there in the rest of the sentence (that you didn't quote all of): "... or as much as possible considering the differences between X11 and Wayland." I'll do my best. It won't be exactly the same, of course, but it will be as close as I can get it. > As an example, focus-stealing prevention. Focus st…

If xfwl4 plans to implement something like sway output max_render_time, then input to pixel output latency should be same or even lower than x11

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#242

Post by Dylan16807 »

scheeseman486 wrote: post #232
rabf wrote: post #171

Earlier quoted context omitted.

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!

It isn't equivelent in the sense that the progressive scanout on CRTs resulted in near-zero latency and with minimal image persistance, versus flat panels which are global refresh adding latency and worsening motion clarity. So it isn't really a "but", it's a "made even better by being rendered only one pixel/dot at a time".

Motion clarity yes, but it's zero latency in the least useful way possible, only true when you're rendering the top and bottom of the screen at different points in time. And scanout like that isn't unique to CRTs, many flat panels can do it too.

When rendering a full frame at once and then displaying it, a modern screen is not only able to be more consistent in timing, it might be able to display the full frame faster than a CRT. Let's say 60Hz, and the frame is rendered just in time to start displaying. A CRT will take 16 milliseconds to do scanout. But if you get a screen that supports Quick Frame Transport, it might send over the frame data in only 3 milliseconds, and have the entire thing displayed by millisecond 4.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#243

Post by array_key_first »

drob518 wrote: post #187
array_key_first wrote: post #181

Earlier quoted context omitted.

I never complained about 60, then I went to 144 and 60 feels painful now. The latency is noticable in every interaction, not just gaming. It's immediately evident - the computer just feels more responsive, like you're in complete control. Even phones have moved in this direction, and it's immediately noticable when using it for the first time. I'm now on 240hz and the effect is very diminished, especially outside of…

Did you use the same computer at both 60 and 144? I have no doubt that 144 feels smoother for scrolling and things like that. It definitely should. But if you upgraded your system at the same time you upgraded your display, much of the responsiveness would be due to a faster system.

Yes same system, then again at 240hz. Realistically I think just about any modern GPU can composite at 240 fps, although I see what you mean if I did an SSD upgrade or something, but I didn't.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#244

Post by eptcyka »

PaulDavisThe1st wrote: post #224
dTal wrote: post #175

Earlier quoted context omitted.

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

Sorry, but systemd has absolutely nothing, or even less than nothing to do with user-space GUI desktop applications.

Systemd runs each userspace desktop application in it's own control group.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#245

Post by gf000 »

kelnos wrote: post #210
LeFantome wrote: post #104

Earlier quoted context omitted.

It is refreshing to see somebody else notice that the complaints about systemd and Wayland are philosophically incompatible. Systemd is creating the same kind of monolith monoculture that Xorg represented. Wayland is far more modular. Regardless of your engineering preferences, rejecting change is the main reason to object to both.

> Wayland is far more modular. Not sure I agree here, assuming you mean "... than X11". With Wayland, you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process. (Though there is a Wayland protocol being worked on to allow moving the WM bits out-of-process.) With X11, display and input-handling are in the X server, and all those other fun…

> you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process

That's an implementation detail. You can absolutely separate one out from the other and do IPC - it just doesn't make much sense to do so for most of these.

The only one where I see it making sense is the window manager, which can simply be an extension/plugin either in a scripting language or in wasm or whatever.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#246

Post by gf000 »

theamk wrote: post #234
coldpie wrote: post #11

Earlier quoted context omitted.

> Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary. Very long time (since 2007) XFCE user here. I don't think this is accurate. We want things to "just work" and not change for no good reason. Literally no user cares what language a project is implemented in, unl…

> Literally no user cares what language a project is implemented in This is only true most of the time - some languages have properties which "leak" to user. Like if it's Java process, then sooner or later user will have to mess with launchers and -Xmx option. Or if it's a process which has lots of code and must not crash, language matters. C or C++ would segfault on any sneeze. Python or Ruby or even Java would stay…

> even Java

That "even Java" that runs half of the internet and most fortune 500 companies business critical infrastructure..

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#247

Post by pjmlp »

gf000 wrote: post #246
theamk wrote: post #234

Earlier quoted context omitted.

> Literally no user cares what language a project is implemented in This is only true most of the time - some languages have properties which "leak" to user. Like if it's Java process, then sooner or later user will have to mess with launchers and -Xmx option. Or if it's a process which has lots of code and must not crash, language matters. C or C++ would segfault on any sneeze. Python or Ruby or even Java would stay…

> even Java That "even Java" that runs half of the internet and most fortune 500 companies business critical infrastructure..

And 70% of mobile market share, that people forget about, even if isn't the proper coffee flavour.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#248

Post by pjmlp »

0x1ch wrote: post #84
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…

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

It is also used on ChromeOS, and on WSL.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#249

Post by internet_points »

jchw wrote: 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…

Long-time xfce fan here, I trust the team to make the right decisions of what to do with their copious spare time and insane amounts of funding

(Instead of seeing this as "xfce jumps on bandwagon", I'm seeing it more as "bandwagon finally stable enough for xfce".)

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#250

Post by fransje26 »

graemep wrote: post #227
kiwijamo wrote: post #207

Earlier quoted context omitted.

Wayland was the first display system on Linux I've used that just worked perfectly right out of the box on a bog standard Intel iGPU across several machines. I think that is a big draw for a lot of people like myself who just want to get things done. For me X11 represents the past through experience I had when I had to tinker with the X11 config file to get basic stuff like video playback to work smoothly without tea…

It is many years, I guess close to a decade, since I needed to change X config manually. I still find the odd rough edge in Wayland (the most recent was failing screenshots with KDE).

> It is many years, I guess close to a decade, since I needed to change X config manually.

Making manual changes in 2015+, for a protocol released in 1987, that's a long time having rough edges..

Post reply on HN