Announcement

Collapse
No announcement yet.

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

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

  • TemplarGR
    replied
    Originally posted by jacob View Post

    I'm not familiar with the details of Mutter and I don't know if it can easily be used outside of GNOME. Another solution for this use-case could be Mir (which is a Wayland compositor now), that's the reason why MATE is considering using it.
    I am not a GNOME developer either, but i find it hard to believe that it can't be easily used outside of GNOME. It might need some GNOME libs, yes, but you don't have to use gnome-shell or gnome-apps with it. And XFCE IIRC already uses gtk, so why not?

    Leave a comment:


  • jacob
    replied
    Originally posted by TemplarGR View Post

    Then, use mutter. Why XFCE refuses to use mutter? The use other libs from GNOME, no? Mutter has a plugin structure, gnome shell is a plugin for mutter, XFCE can create a new XFCE plugin for it.

    It always amazes me that people are this stubborn, they refuse to utilize what is available because of NIH and pride. Mutter is the best Wayland compositor around, the Linux Mint guys forked it and created Cinnamon, and yet DE devs refuse to utilize Mutter because of pride. They do utilize gtk though, i suppose it doesn't hurt their pride.... They use a crapton of libs from GNOME, they use Xserver (which they didn't build themselves), but Mutter? Oh noes not invented here.
    I'm not familiar with the details of Mutter and I don't know if it can easily be used outside of GNOME. Another solution for this use-case could be Mir (which is a Wayland compositor now), that's the reason why MATE is considering using it.

    Leave a comment:


  • TemplarGR
    replied
    Originally posted by jacob View Post

    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.
    Then, use mutter. Why XFCE refuses to use mutter? The use other libs from GNOME, no? Mutter has a plugin structure, gnome shell is a plugin for mutter, XFCE can create a new XFCE plugin for it.

    It always amazes me that people are this stubborn, they refuse to utilize what is available because of NIH and pride. Mutter is the best Wayland compositor around, the Linux Mint guys forked it and created Cinnamon, and yet DE devs refuse to utilize Mutter because of pride. They do utilize gtk though, i suppose it doesn't hurt their pride.... They use a crapton of libs from GNOME, they use Xserver (which they didn't build themselves), but Mutter? Oh noes not invented here.

    Leave a comment:


  • TemplarGR
    replied
    Originally posted by birdie View Post

    The fact that out of all Linux DEs in Linux only the two most financially sound DEs could manage the transition to Wayland and people still have very serious issues working with it 12 years after it was created says a lot about the foundations of Wayland which just totally suck. It's as fast as it's incomplete and broken. I don't really care about "fast" and "secure" when I cannot have my work done under Wayland.
    This is not true. A Wayland compositor is not much different than a X11 compositor. If a DE could support compositing in X11, that DE could make the transition to Wayland with a little bit of work. I am not a XFCE user so i don't know if it offers X11 compositing, but i thought it did.

    Even if it didn't, it could use Sway's library to support Wayland easier. It is a nice library. It could also use mutter, after all XFCE is using gtk, no? Excuse me for not being knowledgeable about XFCE but i never liked it and never used it.

    Anyway, if you and XFCE prefer X11, stay with X11. Just don't complain the vast majority of us transition to Wayland.

    Leave a comment:


  • jacob
    replied
    Originally posted by Terrablit View Post
    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.
    It's not a case of hate of change. It's that that software works, it does everything they expect from it and, in some (many) cases, there simply isn't any direct replacement they could easily migrate to. And since it's still perfectly possible to run DOS software (either natively or with DosBox) and since COBOL compilers are still available and supported, the easiest and safest option for them is simply to keep using what they have.

    Leave a comment:


  • Guest
    Guest replied
    Originally posted by angrypie View Post

    Can't you see it, fool? Wayland is the only way. Forget about basic functionality that exists since Windows 95 and embrace your new display protocol overlords.
    Just for you, and those needing the new game against boredom.

    Leave a comment:


  • Guest
    Guest replied
    Originally posted by Hibbelharry View Post

    What do you think, why are there no xorg X11 Releases? Check the announcment mailinglist archive yourself:


    There are some releases due to migration to gitlab and some smaller fixes, but there is no real progress anymore. Also do your research on xserver 1.21., it's just not happening since a long time. Maybe check the activity here and try to spot something not related to Wayland or being simple compile fixes in 2020:



    That's the exact definition of dead.
    Searching for a new release over and over for everything is a disease.

    Leave a comment:


  • Guest
    Guest replied
    Now stop throlling and change distro.
    Last edited by Guest; 12 April 2020, 02:09 AM.

    Leave a comment:


  • ehansin
    replied
    Originally posted by jacob View Post

    ...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.
    I know I am responding again before getting to the end of the whole thread here, but did want to say something. One things that Sway people are trying to do, with creating the 'wlroots' library is to try and create a standard library (if that is the right thing to call it) that abstracts away a lot of the heavy lifting in creating a new compositor for new window managers, etc. I actually think this could make it easier for people to create a whole new generation of simple, out of the way, shells (i.e fvwm, afterstep, twm - i3 is ready there with Sway). I am absolutely looking forward to this. I am not a coder, I just cannot do so myself. But I think it will happen, and I think it will be great! I don't need a full blown Gnome or KDE desktop environment. Sway is cool, but I think there could be some really cool light-weight possibilities out there to happen. Again, the idea is wlroots can to create a library to do the heavy lifting and make this easier, so each of these does not need to reinvent the wheel. Maybe a better library that wlroots will come along to do even better, but hopefully my point comes across.

    Leave a comment:


  • Terrablit
    replied
    Originally posted by ehansin View Post

    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.

    Leave a comment:

Working...
X