Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • angrypie
    replied
    Originally posted by ehansin View Post

    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.

    Leave a comment:


  • ehansin
    replied
    Originally posted by angrypie View Post

    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.

    Leave a comment:


  • ehansin
    replied
    Originally posted by Terrablit View Post
    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.

    Leave a comment:


  • duby229
    replied
    Originally posted by angrypie View Post

    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.

    Leave a comment:


  • jacob
    replied
    Originally posted by angrypie View Post

    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.

    Leave a comment:


  • leipero
    replied
    Originally posted by jacob View Post

    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.
    Last edited by leipero; 11 April 2020, 08:21 PM.

    Leave a comment:


  • angrypie
    replied
    Originally posted by jacob View Post
    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.

    Leave a comment:


  • lakerssuperman
    replied
    Originally posted by birdie View Post

    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.

    Leave a comment:


  • jacob
    replied
    Originally posted by birdie View Post

    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?

    Leave a comment:


  • birdie
    replied
    Originally posted by jacob View Post

    This is a decade-old list of half truths, FUD, obsolete issues solved long ago and very occasionally sensible points. Wayland applications don't need to implement "their own font anti-aliasing". They use Freetype, which is, among other things, the same engine as on iOS, and of course it has a system-wide settings API. Re DPI settings, it is of course up to toolkits (not applications) because by design, Wayland is all-client-side. Unless you want to do rendering in the server (and there are extremely important reasons why you shouldn't) then it has to be handled on the app side, that is by the toolkit. DPI is of course set system-wide but the rendering adjustments need to be done at the toolkit level. Once again, that's how it's done on both Windows and Mac. From the plethora of half-assed toolkits from the X11 era there are essentially only two left, GTK and Qt, and both ALREADY support DPI scaling so that point is definitely moot. By the way Qt's future as a FOSS-relevant framework is currently in doubt due to the uncertainty regarding its future licensing, so potentially there may really be only one toolkit to worry about. Regarding the game-related issues, I played a couple of games recently and didn't experience any of the so-called problems described there. And so on. Let me know when an actual problem caused by Wayland really arises (NB: "that's not how it was done in X" or "it doesn't work on Xenix 1.0" don't count as problems).
    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.

    Leave a comment:

Working...
X