Announcement

Collapse
No announcement yet.

GNOME 40 Mutter Moves Input Work To A Separate Thread

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

  • #11
    Next step Atomic mode supprt. (The stuff that Roman Gilg mentioned when he asked for more long term planning)
    https://gitlab.gnome.org/GNOME/mutte..._requests/1488

    That pretty much concludes all that is needed for GNOME 40. Of course the big and diverse Mutter team is going to land much much more \o/
    Last edited by 144Hz; 28 November 2020, 07:54 AM.

    Comment


    • #12
      More good news. The more gnome leverages all the cores in modern processors the better.

      Comment


      • #13
        Depending on the way it was implemented, this MR also has the potential to reduce input latency and stalls, since theoretically input events can now reach the clients even when the compositor's main thread is busy.

        Along with https://gitlab.gnome.org/GNOME/mutte...e_requests/168, https://gitlab.gnome.org/GNOME/mutte..._requests/1241 et al this could improve gaming experience as well.

        Comment


        • #14
          I was using multi-threaded applications on the Amiga days... What happened - why isn't important and critical things not in separate worker threads already?

          Comment


          • #15
            I hope they make GNOME more robust too. It is not so robust. Sometimes it crashes, sometimes it freezes. Under Wayland that will bring down the whole compositor.

            Comment


            • #16
              Originally posted by S.Pam View Post
              I was using multi-threaded applications on the Amiga days... What happened - why isn't important and critical things not in separate worker threads already?
              In short, because more complexity is often the antithesis to stability.

              Amiga had a cooperative multi threading model and no memory protections. That allows a whole lot more performance at the cost of security, which also allowed the Amiga to punch above it's weight.

              Comment


              • #17
                Apart from the UI/UX design flaws, either subjective or objective, this was the one biggest architectural flaw in Gnome, am I right? (I'm really asking)
                I'm happy to see this fixed. Moves the whole Linux ecosystem forward and I can't wait to try it on PopOS

                Comment


                • #18
                  Not soon enough it was.

                  Comment


                  • #19
                    Originally posted by LightBit View Post
                    Not soon enough it was.
                    Yes, master Yoda :'D

                    Comment


                    • #20
                      Originally posted by wertigon View Post

                      In short, because more complexity is often the antithesis to stability.

                      Amiga had a cooperative multi threading model and no memory protections. That allows a whole lot more performance at the cost of security, which also allowed the Amiga to punch above it's weight.
                      Whaaaat? Amiga cooperative? No fam, the Amiga operating system was fully preemptive. Sure its system scheduler and the lack of memory protection makes it a bit primitive, but the multitasking wasn't only top notch, back in the day it was impressive for such a home computer.

                      https://en.wikipedia.org/wiki/Exec_(Amiga)

                      Windows 3.x MacOS before X were cooperative.

                      Comment

                      Working...
                      X