Hacker News Reader

Comment by Fiveplus | Hacker News Reader

While I appreciate the author's enthusiasm for the traditional desktop metaphor, this analysis conflates interface familiarity with architectural efficiency. It is a pleasant sentiment please don't get me wrong but technically a bit short sighted. The author praises xfce's modularity and unix-like separation of components (xfwm4, xfce4-panel, xfdesktop), failing to realize that this design pattern is actually a performance antipattern in the modern display server model.

In the X11 era, the server arbitrated these components. In the Wayland era (which I must assume is the baseline context), the compositor is the server. Forcing the panel and window manager to communicate via IPC rather than sharing a memory space in a monolithic compositor introduces unavoidable frame-latency and synchronization issues. Issues specifically regarding VBLANK handling and tear-free rendering that integrated environments like plasma or sway solved years ago.

View on HN

As a decades-long Xfce user, I greatly value Xfce's modularity, and don't care the slightest bit about improving the display server performance. Xfce is already snappy well beyond my level of sensitivity, and I won't trade the flexibility I have and use for a sliver of extra performance I don't even think I might need.

(Yes, it's plenty snappy on an external 4K@60 monitor. A desktop environment is not a competitive FPS where a single extra frame of latency lowers your chance of being productive.)

But maybe people want to run XFCE AND play competitive fps?

It would be embarrassing for gnome to be more performant there than XFCE.

Don't full-screen apps sidestep the DE compositor anyway?

It's a specific setting in XFCE you have to turn on, and most people try to bypass it anyway by manually disabling the compositor with hotkeys. Auto detection of the full screen windows has been hit or miss, especially when running things through proton/wine.

Also with x11 if you go through the steps to get Variable Refresh Rate going and you are dual monitor, it will max the refresh of both to the slowest monitor. :(

Wayland doesn't have that issue.

These are valid concerns for those who spend more time playing maybe. I mostly work, all of my monitors are 60Hz, and I only play single-player games.

If I were into hardcore gaming, and used the same machine for daily work, I would likely just end the X session, and switched to a minimalist Wayland session with a menu of games for the entire desktop.

I understand what you are saying about efficiency in theory.

Though I must say, 20 years ago, I used X based desktop environments on hardware at the time and they were blazingly fast. Today's Gnome doesn't even come close. How can that be, if they were so ineffcient?

> Today's Gnome doesn't even come close. How can that be, if they were so ineffcient?

We call this evolution.

XFCE is X11-only, isn't it? Wayland support is still in development/experimental. I personally use XFCE with X11 to this day.

OpenSUSE Leap 16 has Wayland-only Xfce 4.20, using LabWC as the WM/compositor.

It works but keyboard-driven window management is broken: LabWC doesn't understand the standard (i.e. Windows) keystrokes.

Fvwm ran exactly that way on my Pentium-60 and I do not recall ever experiencing performance or latency issues; matter of fact, my Linux desktop of the time was more efficient than Windows. The FvwmPager, FvwmButtons, and FvwmTaskBar modules are separate programs launched by fvwm and communicate with it via IPC. Sacrificing modularity to avoid performance issues that were hard to see even on machines from 30 years ago—let alone on today's hardware—is a bit penny-wise and pound-foolish.

> In the Wayland era (which I must assume is the baseline context)

But that's not where we are, a lot of people still haven't moved and XFCE only has premliminary support for wayland at this time.

But it doesn't matter, xfce on X is still great.

Xfce runs decently on my 10 year old 2-core Atom laptop with 2GB of RAM. It might use some inefficient patterns, not sure about that. But all the modern bloat software has brought basically little added value while eating much more resources, despite the claimed efficiency improvements.

What? The window manger and the panel (plasmashell) are separate processes in a Plasma desktop. In Sway, users typically choose from a range of totally separate applications like swaybar or quickshell for the panel. There’s absolutely no reason the panel has to be coupled with the compositor under Wayland and nobody actually does it that way that I’ve seen.

Can you quantify those performance problems? Would I notice them on a 2018 vintage laptop?

Just thinking out loud here, but even if it’s a performance anti pattern, xfce is a light weight de so you wouldn’t see it over all I guess.

To my eye most Linux de’s are much lighter or responsive than windows or Mac

Hmm, I'd say that on a 2018-era machine, you won't measure this in raw CPU throughput. In all probablity, your cores are fast enough to mask the context switching. The performance deficit here is strictly in the domain of motion-to-photon latency or frame pacing. I guess my point is that in xfce's split architecture, the compositor acts as just another X11 client.

This enforces a path where window contents often round-trip through the X server before composition. Quantitatively, this typically adds at least one frame of input lag compared to the zero-copy direct scanout path available to monolithic wayland compositors. You likely won't notice this while editing text. However, the architecture doesn't perform well when you attach an external monitor. Since X11 shares a single virtual coordinate space, it cannot synchronize VBLANK across two outputs with different refresh rates or clock domains.

ps: and please don't call your 2018 machine vintage, it makes my secondary thinkpads feel prehistoric :D

My newer desktop (2020 era with a 3070) has 4x 4k monitors attached running XFCE and I have never noticed the lag you speak of. I don't run external monitors on it but my thinkpad x200 with a core 2 duo also does great with xfce.

I have no doubt the issues you speak of exist in theory but they do not seem to matter in practice.

You shouldn't notice lag. On modern Xorg the only round-trip is context switches between server and compositor, because the only thing what is shared is texture dma-bufs (there is inefficiency in mesa code for GLX_EXT_texture_from_pixmap extension, but it is other story). And if dma-bufs is working (Xorg needs to test and pull one MR) you have buffer direct scanouts as in wayland.

As someone who runs modern XFCE on a core 2 duo I still have without noticable perf issues, the problems the parent talks about are theoretical and not observable.

I am running XFCE on a 2019 vintage desktop. CachyOS and 16GB RAM. It is snappy and very performant for my needs and I work on it daily for software development

16gb of memory an. 2019 is not vintage lol.

2019 is also not vintage IMO.

Vintage would be my MBP Air from 2011 that also run Arch and XFCE on a 4GiB RAM.

I do not know what xfce really has to do with X11 vs Wayland, but you could - if one wanted - build an X server that integrates a compositer and window manager. I do not think this has any real technical advantage and I think a modular design is stronger from an engineering point of view.

Tear-free is more a driver issue, I also do not see any Wayland advantages here. Probably xorg does not enable it by default

What are you talking about? Author is talking about user experience, they way changes (as far as user is concerned) Do Not Happen (much), how they don't try to invent new UI paradigm (cough Gnome cough) and are Not Fucking It Up (cough KDE4 cough).

As a user I don't care about X11 / Wayland. I mean I do, from the security viewpoint, but not otherwise. Xfce could port itself to Wayland and (if done properly) I wouldn't even notice. It is nice to know that on any Linux machine I can install UI desktop environment which is usable, dependable and... complete.

I love Xfce and hope they never change. Kudos to everyone involved!

I’d say optimizing a WM like this makes sense. Why would I want to optimize a panel or desktop?

Reply on news.ycombinator.com