Announcement

Collapse
No announcement yet.

Another Intel 4K + GNOME Optimization Yields 5% Faster Render Times, 10% Lower Power Use

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

  • #11
    brent Oh you were just here to happy troll a bit and didn’t knew how Daniel works. He keeps repeating the same speak on Gitlab. Never guess, always profile. Never do premature optimization, work on what matters.

    Comment


    • #12
      Originally posted by 144Hz View Post
      brent Oh you were just here to happy troll a bit and didn’t knew how Daniel works. He keeps repeating the same speak on Gitlab. Never guess, always profile. Never do premature optimization, work on what matters.
      If you have window culling code implemented and it isn't running then it should be removed or the bug fixed. It isn't premature optimization if you are fixing something that is suppose to happen.

      Comment


      • #13
        The question is, what are the rest of GNOME devs doing, besides outreachy and other bullshit? Without Daniel there would be no Gnome Shell or Mutter

        Comment


        • #14
          Originally posted by 240Hz View Post
          The question is, what are the rest of GNOME devs doing, besides outreachy and other bullshit? Without Daniel there would be no Gnome Shell or Mutter
          Are you really this stupid, or are you just trolling? You know that the commit history is public, so you could actually check... but I assume you might not have the skills to actually do that.

          Comment


          • #15
            Originally posted by 144Hz View Post
            brent Oh you were just here to happy troll a bit and didn’t knew how Daniel works. He keeps repeating the same speak on Gitlab. Never guess, always profile. Never do premature optimization, work on what matters.
            I'm fully aware of what Daniel does and I'm really glad that he's doing this work! Unfortunately, it took a LONG time until someone with this kind of this focus on performance showed up. I'd say it was a management mistake that the GNOME community leadership did not recognize that performance is paramount for a desktop environment, particularly if it involves as much interactivity and animations as GNOME. Bug reports about major performance issues go back to 2010, and were a common occurence, yet nothing serious was done to analyze the problems and fix them.

            For many years, the GNOME community worked mostly on features and fancy UI and largely ignored performance. Sure, some people worked on various improvements here and there, but there never was any concentrated effort and regressions happened approximately as often as improvements.

            I hope we'll see some (automated?) performance regression testing effort in the future. That's an area where GNOME is still lacking a lot and it allowed the culling bug to happen without anyone noticing.

            Comment


            • #16
              Originally posted by AnAccount View Post

              Are you really this stupid, or are you just trolling? You know that the commit history is public, so you could actually check... but I assume you might not have the skills to actually do that.
              You are aware that number of commits is not everything right? Quality also matters. I am sure there are plenty of commits changing "master" to "main" or whatever

              Comment


              • #17
                Originally posted by 240Hz View Post

                You are aware that number of commits is not everything right? Quality also matters. I am sure there are plenty of commits changing "master" to "main" or whatever
                Well the actual changes are also there, but that actually requires some knowledge to understand I guess.

                Comment


                • #18
                  I think that all windows managers and desktops environment was made by band of "hippies" and they never really target on real users for day to day usage.
                  So all users and linux fans just say yee it is working it isn't really great but it is FREE. And that matter!

                  And then android came and then chrome OS came
                  And somebody from back said woow it is great and it is FAST. They don't need 1TB of RAM and 10GHz CPU to run.
                  Why android and chrome os are "fast" but gnome/KDE and others isn't
                  And that was the moment when you can compare.
                  So it wasn't about intel, nvidia amd. They can't blame drivers anymore. It is all open source now.

                  So we should thank you for that moment

                  gnome developers should use SBC devices as raspberry pi or odroid or something with intel atom.

                  Comment


                  • #19
                    miskol android was not really fast from the beginning their jit approach with all that java stuff made it ultra portable but comparable slow to iOS and Windows phone with same horsepower at that time. I would say it became faster around android 6-7 ..afaik this was the time when they have implemented some time ahead compilation when the APK got installed. IMHO android is still wasting resources compared to iOS.

                    P.s. I remember my first contact with Android gingerbread 2.? ...my first impression cool it runs on Linux but why is it so slow my desktop is snappier? It at that time some flagship device.
                    Last edited by CochainComplex; 06-26-2020, 11:29 AM.

                    Comment


                    • #20
                      Originally posted by 240Hz

                      The fact that you think reading commits requires some skill and knowledge shows how little you know. The fact that you are so proud of being able to read commits says a lot as well, are you an outreachy developer?
                      And yet, you obviously haven't been able to do it.

                      Comment

                      Working...
                      X