Announcement

Collapse
No announcement yet.

Ubuntu 20.04 LTS To Optimize GNOME For Fast/Modern PCs, Ubuntu 20.10 For Slow/Older PCs

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

  • #21
    Originally posted by GrayShade View Post
    Gnome dev caring more about 3D windows than a 2x CPU usage reduction (note % vs. pp, and the overall results hidden in a subthread at https://gitlab.gnome.org/GNOME/mutte...#note_586419):
    Yes, because GNOME Shell isn't the only user of Mutter and it's a supported feature. People seem to complain when GNOME removes something then complain when they don't.

    A solution was eventually found that didn't rely on breaking implementations and was eventually backed up by proper performance statistics, rather than unreliable numbers.

    Comment


    • #22
      Originally posted by Mario Junior View Post
      Maybe rewriting gnome from zero solves the problem.
      Fine. When will you start to do it? :-P

      Comment


      • #23
        Britoid, maybe you know, is anyone at Gnome team have plans for Gnome OSK improvements? (Onboard from year 2017 is still much, much more usable, but not available in Wayland session.) Or maybe at least make fractional scaling available on HD displays, and make higher scaling (225%, 250%, 275%, 300%) available for HiDPI displays? (Like HP Pro Tablet 608 G1, 8 inch, 2048x1536, 200% is clearly not enough.) All bugreports is filled, I don't pressure anyone, and patiently waiting. Just hope maybe you have some information about these issues.

        Comment


        • #24
          Originally posted by RussianNeuroMancer View Post
          Britoid, maybe you know, is anyone at Gnome team have plans for Gnome OSK improvements? (Onboard from year 2017 is still much, much more usable, but not available in Wayland session.) Or maybe at least make fractional scaling available on HD displays, and make higher scaling (225%, 250%, 275%, 300%) available for HiDPI displays? (Like HP Pro Tablet 608 G1, 8 inch, 2048x1536, 200% is clearly not enough.) All bugreports is filled, I don't pressure anyone, and patiently waiting. Just hope maybe you have some information about these issues.
          I don't know of any work on the OSK but I agree the OSK is in a pretty bad state.

          Imho https://extensions.gnome.org/extensi...reen-keyboard/ sort of functionality should be mainlined. The Purism people are also working on an OSK that's for their phones that could end up coming to desktops and is independent of the shell.

          Comment


          • #25
            Originally posted by Mario Junior View Post
            Maybe rewriting gnome from zero solves the problem.
            ... in Rust!

            Comment


            • #26
              Originally posted by Britoid View Post

              You can't provide references because you're lying. Performance is regularly discussed on the GNOME Matrix/IRC channels, at GUADEC and the various Hackfests. He wasn't at them, so to randomly get a MR out the blue that works on something that was already actively being worked on, then to add fake [performance] labels to them without proper benchmarking and then have people creating Gitlab accounts to throw insults at the GNOME maintainers for not merging them isn't right. I give that the latter isn't Daniels fault, but the [performance] tags in the title didn't help.

              GNOME devs do care about performance and do appreciate the work he does, he's great at finding problems and working on a compositor is no easy challenge. But GNOME is a community project that's ultimately deployed in commercial settings, MRs need to be scrutinized and work needs to be communicated.
              I'm sure you've had thousands of hours of academic discussions on how to improve performance in Gnome, but certainly with very little to show for it for years. Not until canonical, and specifically Daniel, got involved again did Gnome see any improvements whatsoever in that regard. Previous art isn't worth crap if it's a half baked idea or even a mere discussion months before in an IRC channel nobody's bothering to push through the finishing line. You either get results, or make way for people who do. The amount of crap and hostility the poor guy has put up from some core gnome devs for the last 2 years is painful to watch.

              Getting flak from users on gitlab isn't nice, that's for sure. But the fact a sizeable amount of people take the time to create an account to complain comes to show the level of frustration your users have with your product. You have a very poor record at listening to user's feedback, or at least at communicating to users "look people, we know this is a problem, we're working on it".
              Last edited by royce; 25 October 2019, 01:09 PM.

              Comment


              • #27
                Originally posted by royce View Post

                I'm sure you've had thousands of hours of academic discussions on how to improve performance in Gnome, but certainly with very little to show for it for years. Not until canonical, and specifically Daniel, got involved again did Gnome see any improvements whatsoever in that regard. Previous art isn't worth crap if it's a half baked idea or even a mere discussion months before in an IRC channel nobody's bothering to push through the finishing line. You either get results, or make way for people who do. The amount of crap and hostility the poor guy has put up from some core gnome devs for the last 2 years is painful to watch.

                Getting flak from users on gitlab isn't nice, that's for sure. But it comes to show the level of frustration your users have with your product. You have a very poor record at listening to user's feedback, or at least at communicating to users "look people, we know this is a problem, we're working on it".
                The move to Gitlab really helped in the last couple of years to speed up development. Before development took place with a mix of mailing lists, git repos and bugzillas that was fairly inconvenient. Gitlab moves that all into one place where code can be commented on, proposed, discussed etc.

                I'm not part of GNOME and certainly don't speak on behalf of the GNOME Foundation. But I work on applications in the "GNOME"-sphere and keep track of development and I have spotted a few untruths that get shared a lot which aren't really true.

                Comment


                • #28
                  Apologies, substitute "you" for "gnome".

                  Comment


                  • #29
                    Originally posted by Mike Frett View Post
                    Seems backwards. The LTS should be optimized for slow machines and 20.10 for fast machines.
                    Not really. It all depends on the user demographics. If most of their users are on modern machines (which is to be expected) then it makes sense to optimize for the majority first.

                    Comment


                    • #30
                      Originally posted by rastersoft View Post

                      Fine. When will you start to do it? :-P
                      Tomorrow

                      Originally posted by bregma View Post
                      ... in Rust!
                      Assembly and C. Are all you need.

                      PS: I'm not a programmer, developer or something, so I don't have no idea of what I talking about.

                      Comment

                      Working...
                      X