X.Org vs. Wayland Browser Performance With Firefox + Chrome

[jacob]

You haven't addressed a single issue pertaining to Wayland listed in the article. And there are no half truths are in the list as it's constally and gradually updated when people really have sound arguments. You've got none so far. A typical Linux fan-atic. Screaming off the top of your lungs while shutting your ears: "WE HAVE NO PROBLEMS". Yeah, that's why no one wants to touch Linux: neither users, nor ISVs. Lmao. I wonder how many years of schooling you've got behind your back - I presume not that many. Four? Five? You definitely couldn't have graduated from it. Your reasoning abilities are null and void.

I have addressed two: font anti alisaing and DPI scaling. Do you want me to go in detail into each and every one? In fact i agree with what you did there, except that the roles are in reverse: it's the *nix/X11 crowd that is chanting "WE HAVE NO PROBLEMS". It's the Wayland devs who recognise the problems and work on solving them. But of course, these guys have only been "THE X people" for the past 20 years or so, what would they know, right?

[lakerssuperman]

You haven't addressed a single issue pertaining to Wayland listed in the article. And there are no half truths are in the list as it's constally and gradually updated when people really have sound arguments. You've got none so far. A typical Linux fan-atic. Screaming off the top of your lungs while shutting your ears: "WE HAVE NO PROBLEMS". Yeah, that's why no one wants to touch Linux: neither users, nor ISVs. Lmao. I wonder how many years of schooling you've got behind your back - I presume not that many. Four? Five? You definitely couldn't have graduated from it. Your reasoning abilities are null and void.

What? Numerous points from the article were addressed in that response. Font rendering. DPI scaling. Toolkit support. Game related performance. All of them listed in the article and all addressed.

[angrypie]

We can expect that with Wayland, the tradition of people writing various little window managers (like we had fvwm, afterstep, i3 etc...) will probably vanish; there will be Gnome, KDE and perhaps Sway.

Xfce will likely survive and, supposedly, wlroots is there to make it easy to write Wayland compositors.

If IceWM dies I'll resurrect it with my own two hands.

[leipero]

DISCLAIMER: I have no personal interest in Wayland, no stock etc. But I'm 100% convinced that it's the future and the way to go, not necessarily because it's the best a windowing system could ever be, but because it's the only project that we have that is in a position to succeed. And while not perfect it's actually pretty damn good.

Regarding your point about performance: it's a common misconception that wayland is slower than X and it comes from two confusions. Technically it is almost impossible for Wayland to be slower than Xorg because it uses the same rendering engine, the same drivers and the same code paths as modern composited X sessions, without the unused X server in the way and the associated context switches from the app to X to the compositor to the window manager and back. When people complain about Wayland being slower they in fact almost always mean X11 apps running on top of Wayland through XWayland, not native Wayland apps. There is little fundamental reason why XWayland should be slower than native X but in practice it seems to be the case, even though as recent benchmarks published by Michael show, the difference is often not noticeable. If you run native Wayland software (GTK3-based etc.) it's already faster than X11 today, and it literally flies: Nautilus windows finally resize smoothly and without lag or artefacts, the desktop reactivity is FINALLY on par with Windows 10 on the same machine, etc.

The second reason is that in a Wayland session, the compositor handles more tasks than under a composited X session and it is really performance critical. A poorly implemented compositor will have a much bigger performance impact on Wayland than on X11. It's a reality that virtually all compositors that people actually use (not talking about Weston...) are ports from X11 compositors. Only Gnome Shell 3.36 comes close to being what a native Wayland compositor should be; it's not quite there yet, but it's getting close. In other words implementing a good Wayland compositor is much more performance critical than on X11 and it's much more challenging than writing a X11 window manager. We can expect that with Wayland, the tradition of people writing various little window managers (like we had fvwm, afterstep, i3 etc...) will probably vanish; there will be Gnome, KDE and perhaps Sway.

If you say that X11 security has been proven through time, I disagree. It has been proved to require many various kludges and band-aid fixes to remain acceptable, and if disaster never stroke it's in no small part thanks to the fact that malware (especially desktop malware) is much less common on Linux than on Windows. The fact remain that even today there is absolutely nothing to stop a program from invisibly recording your entire desktop session and streaming it out, and you would probably never notice.

The reality is that Wayland will never reach exact feature parity with X11 because by design it's not meant to. There will never be a version of sxhkd or "ssh -X" for Wayland, which doesn't mean that there will be no support for hotkeys (but it will have to be implemented as a compositor add-on, not as a user daemon) or that there will be no remote administration - that will have to be done using a combination of RDP and Web applications. If you expect a Wayland powered Linux to be the same thing as X11-linux with the same use cases and the same kinds of applications, then you WILL find Wayland inferior. But that's absolutely not the point.

What I gather from your post is that Wayland is not on feature parity with X, so using my argument of 'features vs performance', you can theoretically argue that Wayland is faster by default.
Second thing I've got is that you really need GTK3+ applications in order to see semi-good implementation of wayland protocol and that is already faster than X today (with GNOME 3.36).

However, from my own experience none of those things you are suggesting are true. For example, nautilus (files in gnome) is GTK3 based application, if your theory is correct, that application should behave faster under wayland, that simply isn't the case. Maybe it is 'smoother' on broken/bad hardware, but it's not faster nor smoother (on resizing etc.) on non/less-malfunctioning hardware-software combination in comparison to X.
How protocol is supposed to work usually doesn't have much to do with how it is actually implemented (and you said that by yourself in your post concerning other compositors etc.), the reality is that I do not know how many calls for the same task wayland does in comparison to X, how many lines it does and so on, I don't know if you know that, but I don't, technically AFAIK, more lines = slower code = less performance per cycle (eg. same conditions). Now granted, it really depends how much of that code is executed for specific task or group of tasks (as it is the case for compositor, window manager and protocol), I never tested that, nor do I know where to begin, but there is actual scientific way to prove if wayland is actually faster or slower than X based on that study alone (with same/similar conditions applied).
Either way, it surely doesn't feel that it is anywhere near as fast as X, that's all I can say, and I will gladly move to wayland once it becomes usable, so far, for me, it simply isn't and that's where it ends.

As for security, there were no major (if any) attacks and harm done to someone (or group) thanks to the X windowing system as far as I know, and even if there was, it's really nothing in comparison to other components of the system, so that argument is equally as poor as the age of the system (being old, made in 80's, bla bla and similar c**p like that, like it matters...). Besides, with complex systems (such as wayland, X or any of such larger projects), who can say that there is no and that there will not be security issues of other nature in comparison to each other, so that's really poor argument IMO.

[jacob]

Xfce will likely survive and, supposedly, wlroots is there to make it easy to write Wayland compositors.

If IceWM dies I'll resurrect it with my own two hands.

All the best to you, but wlroots only makes it easier to handle the Wayland protocol, not implementing a compositor as such. A traditional X11 window manager like IceWM etc. is a project for a hobbyist or an enthusiast, but a Wayland compositor definitely isn't due to its inherent complexity and stringent performance requirements. As an analogy it may be possible for someone to decide to resurrect Linux 1.0 with his own hands; but no single individual or even a small team can set out to resurrect Linux 5.x. A hobbyist can write a toy compositor for Wayland, but not a performant, production quality one usable on a wide range of hardware and workloads.

[duby229]

Xfce will likely survive and, supposedly, wlroots is there to make it easy to write Wayland compositors.

If IceWM dies I'll resurrect it with my own two hands.

Icewm is awesome, it literally takes just 1 minute to compile and it works on almost nothing. As far as a desktop like environment goes it's waaaay better than Gnome3, which doesn't say much about icewm, but does say boatloads about Gnome3.

[ehansin]

ITT: Trolls who think a benchmark about one application with similar scores justify ostrich-like avoiding of decades of improvements in software architecture in computer science. As if the application being able to run on both stacks wouldn't interfere with it's ability to take advantage of the better platform. Portability is adjusting to the lowest common denominator, and the lowest common denominator is whatever X can deal with.

X is not scalable. It worked passably well when UIs revolved around line stippling and rectangle drawing, but now that applications are rendering their own surfaces with low-level graphics APIs, it gets in the way more than anything. It obstructs display advancements at every turn. We've tacked on extensions to try and help it deal with that. And we've done reasonably well. But that's just 3 decades of polishing a turd. It's shiny as fuck, now, but it's still a turd. Underneath that smooth, mirror-like reflection of your face it's still shit.

No one wants to maintain it. Hear that? Everyone who works on it hates it. It's already dead. The only work that goes into it is work that's forced (like for security reasons). The people who understand it don't want to put any more effort into it. If the writers and maintainers see it as a dead platform, the users either need to step up and maintain it themselves (unlikely, as competent graphics engineers are more interested in following the current progress than maintaining cruft that predates them) or deal with the reality that their product has already been end-of-lifed.

Comparing Wayland to X as if it's an actual competitor is foolish. The dead don't compete with the living. They just sit in the ground and rot. Yeah, we've still got a ways to go to feature parity. Track missing features and help fix bugs. Cooperate instead of dragging your feet. Don't blame the devs for not doing what you want when they know more about the tech stack than you do. In short: figure it out.

I didn't even read the rest of the comments before replying here. Thanks! I'm no expert, but I know enough who is working on this and has also worked on X to know you got good points here. Is Wayland the end all be all? Things are not static, of course in the future there will be better options. But sounds like people in the know are behind Wayland.

[ehansin]

Where's your cyanide drink, cultist?

I'm not an expert on things, but given the fact that all the major X devs seem to back Wayland, you really do sound like an 'angrypie'. Just saying.

[angrypie]

I'm not an expert on things, but given the fact that all the major X devs seem to back Wayland, you really do sound like an 'angrypie'. Just saying.

Well, duh?

I don't care about who backs Wayland, because I know that, I care about changing stuff while regressing 30 years in usability. No Wayland compositor implements all of the functionality available in their Xorg counterparts. Try explaining to a new user why tooltips show up on the other side of the window. If you don't want to be called a cultist, don't act like one.

[Terrablit]

I didn't even read the rest of the comments before replying here. Thanks! I'm no expert, but I know enough who is working on this and has also worked on X to know you got good points here. Is Wayland the end all be all? Things are not static, of course in the future there will be better options. But sounds like people in the know are behind Wayland.

It's currently the only viable path forward. There's no new projects offering similar functionality, and there's only maintenance work on older projects. Whether it will stay that way for another 3 decades is another question. Generally open source projects can stay in the lead until they get bogged down in management or technical debt, at which point people start considering a fork or a rewrite. That's how Wayland started after all. It was designed as a protocol is an attempt to decouple things and make it easier to extend. I personally think doing it as a protocol might be on the side of over-engineering, but that's perception, not fact. The downside of the protocol focus is that it's a steep climb to the first compositor implementation for a lot of windowing managers. It's why most of the available Wayland compositors have their own toolkits and larger teams.

People complained about that a lot, so the Wayland team started putting more effort into libraries. It's gotten better since those libraries have matured. Having more desktop people involved in Wayland has accelerated its growth. I'd like to see libwayland-client and libwayland-server develop to the point that it covers most of the stuff the vocal luddites want from X and makes it easier for X WMs to port their code over. Having all the basics in the reference implementation would go a long way towards putting this flamewar to rest.

There's been comments that a lot of the annoyances with Wayland wouldn't exist if we had a single toolkit for the desktop. That's a common complaint in one of the linked outdated "Wayland's not good enough" articles. It's arguably true. Multiple desktop toolkits cause a lot of issues on the Linux desktop. Preserving portability and compatibility requires a lot of extra work. However, no one would agree on which toolkit to use, and would object to being forced to use a new one (and the wasted effort spent on it). People have been fighting over GTK vs Qt for decades now. They even care deeply about the language used (C vs C++) in development of them. They used to complain about having to have the other toolkit installed when they only wanted the one they liked. A big reason for why Wayland is designed the way it is boils down to preserving that choice that the community so vociferously defends. They want to choose even if that choice is wrong. And since a lot of software development is about tradeoffs, what's "wrong" is subjective to what individuals prioritize. Hopefully broadband and storage improvements will make the dependency demands less relevant.

It's sort of the same situation with systemd. They also had to choose an init platform to focus their service management work on. Systemd, though, just rolled their own instead of worrying about cooperating with everyone else. It's mostly been a success, and it's been greatly appreciated by package maintainers and the more open-minded sysadmins. But something like 2% of the community hasn't stopped screaming about it since, treating it like a tragedy and a conspiracy.

It just goes to show you that people hate change. Many businesses still use DOS-based point-of-sale systems. Banks are still using COBOL-based software on mainframes. They want to ride that stability wave into the ground even if it makes the inevitable migration much harder, because it cuts down on short-term effort. And sacrificing long-term benefits for short-term gains is the mindset that drives our capitalist economy.