Announcement

Collapse
No announcement yet.

Ubuntu 13.10 Desktop Tests: Unity 7.1, KDE 4.11, Xfce 4.10, GNOME 3.8

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

  • #16
    Originally posted by droste View Post
    Give it a try. You will probably use compositing with OpenGL (2 or 3.1) and Qt qith raster graphics system, like every one else (*). So XRender speed isn't that interesting at all.

    * http://userbase.kde.org/Desktop_Effe...raphics_System
    None of the people here who are like "ZOMG!!! GtkPerf SO SLOW!!!" actually understand what the benchmark does any and how it would affect you in day to day use.

    Comment


    • #17
      What are the odds that we could gets some insightful analysis on WHY the results are what they are?

      For example, LXDE is a lightweight desktop, so why are QGears so weak in comparison with XFCE, Is it because it's based on Qt?

      Why is KDE is slow on GTKPerf, is it because of GTK libraries, or was it testing HDD I/O while KDE was indexing files? I understand that it's a heavier desktop, but when something that's supposed to take ~ 1.5 seconds (on every single other DE) ends up taking 16, I'm not sure you can write that up to performance. If something takes 15 times longer, doesn't that count as a system failure/collapse, where you're supposed to fix the bug first?

      And what about the games in the middle? Are those results more what you would expect in the "real world" with no real difference? Or, are they so similar because they are not typical workflow and just pushing everything onto the graphics card?


      My point is simply this: I'm not an expert on these DEs, or the methods used to benchmark them, but I would really love it if someone would give some context and insight into what exactly is happening that is causing those green bars to differ (or not).

      Comment


      • #18
        Originally posted by StephanG View Post
        What are the odds that we could gets some insightful analysis on WHY the results are what they are?

        For example, LXDE is a lightweight desktop, so why are QGears so weak in comparison with XFCE, Is it because it's based on Qt?

        Why is KDE is slow on GTKPerf, is it because of GTK libraries, or was it testing HDD I/O while KDE was indexing files? I understand that it's a heavier desktop, but when something that's supposed to take ~ 1.5 seconds (on every single other DE) ends up taking 16, I'm not sure you can write that up to performance. If something takes 15 times longer, doesn't that count as a system failure/collapse, where you're supposed to fix the bug first?

        And what about the games in the middle? Are those results more what you would expect in the "real world" with no real difference? Or, are they so similar because they are not typical workflow and just pushing everything onto the graphics card?


        My point is simply this: I'm not an expert on these DEs, or the methods used to benchmark them, but I would really love it if someone would give some context and insight into what exactly is happening that is causing those green bars to differ (or not).
        Every DE uses resources. The main 3 are RAM usage, CPU usage and GPU usage (core and memory).

        In this kind of benchmarks (gaming) usually the RAM usage is not affecting the game performance because usually RAM size is more than in enough in the system (hardware) they are benchmarked.

        So the less CPU and GPU resources the DE is using, the better performance a game has. Of course there are some optimizations that every DE does to perform better. Bright example on that is Unity with the compositor bypass technique on full screen games.

        Now for your question about LXDE and XFCE, don't judge a DE's performance from what you see in the surface. LXDE may be less RAM intensive DE than XFCE and simpler too but the same time it seems its more heavy on CPU and/or GPU resources and/or less optimized than XFCE.

        Unity and XFCE are the fastest and/or optimized DEs right now (as Phoronix benchmarks have proved) and on the opposite KDE is the worst.

        On the other hand performance has nothing to do with the "feeling" every DE gives you as a user. "Smooth" some times is more important than "Fast" and there is the hardware factor always when you choose what DE fits you most. for example Unity may be fast and smooth but the same time a PC with 1GB RAM will bottleneck this DE so XFCE is recommended there.
        Last edited by verde; 08-31-2013, 09:00 AM.

        Comment


        • #19
          Originally posted by chrisb View Post
          Something is seriously wrong with GtkPerf on KDE..
          Probably the theme engine is different when running on KDE? I can't think of anything else that would account for such a huge discrepency on KDE but almost no variation between the others. I'm guessing the others all use the default theme, while KDE is using something that integrates better with the KDE look-and-feel?

          Comment


          • #20
            Originally posted by StephanG View Post
            Why is KDE is slow on GTKPerf, is it because of GTK libraries, or was it testing HDD I/O while KDE was indexing files? I understand that it's a heavier desktop, but when something that's supposed to take ~ 1.5 seconds (on every single other DE) ends up taking 16, I'm not sure you can write that up to performance. If something takes 15 times longer, doesn't that count as a system failure/collapse, where you're supposed to fix the bug first?
            Possibly bug 275665
            Also, after investigating, the gtkperf deterioration between 1) and 2) is *not* due to the resize bug. It is due to the special background rendering for groupboxes, which is practically as complex as the "normal" window background and painted on top. Better rendering, lesser performance.

            What hits us here is that all gtkperf windows are inside Groupboxes, so the background gets re-painted a lot of times.
            Apparently it does cause a noticeable impact on some apps (Bug #280000 Laggy and slow scroll on Inkscape docked dialogs).

            I'm not sure if we are able to overcome this problem, since we are forced to make such inefficient hacks to implement the features we try to. It's GTK+ limitations which make us do such ugly hacks....

            Oxygen rendering path is much more complex than qt curve, due to gradients, animations, etc.
            It is therefore expected to be slower and this does not make it a bug. It is your call to decide between performances and features

            Comment


            • #21
              The widgets theme does indeed have a very significant impact on performance. I ran the tests where KDE performed particularly poorly on my machine. I run KDE 4.11, VSync in KWin was switched off. Qt rendering engine was set to Raster (I forced Raster during tests in TWM too). My machine is a sorry-ass 4 year old laptop with T9550/nVidia 9800GTS (proprietary drivers v. 325.15).

              QtPerf QCheckBox 5000x (sec)
              In KDE with KWin:
              - Qxygen: 1.634 0.087
              - QtCurve: 1.403 0.055
              - CDE: 1.363 0.377
              In plain TWM:
              - 1.334 0.206

              GtkPerf GtkCheckButton 5000x (sec)
              In KDE with KWin
              - Oxygen-gtk: 6.84 0.61
              - QtCurve: 2.47 0.07
              - Raleigh: 1.61 0.07
              In plain TWM:
              - 1.54 0.03

              QGears2 COMPO (FPS)
              - Qxygen: 273.224 3.358
              - CDE: 558.729 15.183
              The performance more than doubled. If you multiply the result Michael got, you'll see that KDE is on par with other DE's except Unity.

              I believe this shows that there is nothing wrong with KDE's/KWin's rendering performance. It's also worth noting that KWin in KDE 4.11 introduced improved VSync which could have impacted the performance, especially if it wasn't set correctly. Folks with Intel GPU's could give this a try...

              Comment


              • #22
                Also see benchmark results at http://www.serkey.com/ubuntu-gtkperf...in-bfkcp5.html where gtkperf on kwin takes three times longer than KDE with no effects.

                Comment


                • #23
                  Where these results with or without XMir?

                  Comment


                  • #24
                    Originally posted by dh04000 View Post
                    Where these results with or without XMir?
                    Please... Read the first page of the article...

                    all desktops were running directly atop an X.Org Server without any use of Mir/XMir.

                    Comment


                    • #25
                      This is clearly an Oxygen-gtk issue. I ran a few benchmarks where KDE 4.11 performed particularly poorly myself to verify that. I used my 4 year old laptop with T9550/nV 9800 GTS(props v. 325.15). KWin compositing was on, VSync set to "None", rendering engine "Raster", OpenGL 3.1.

                      QtPerf, QCheckBox test 5000x (sec)
                      Oxygen: 1,634 0,087
                      QtCurve: 1,403 0,055
                      CDE theme: 1,363 0,377
                      ---
                      Plain TWM (raster engine enforced): 1,334 0,206

                      GtkPerf, GtkCheckButton test 5000x (sec)
                      Oxygen-gtk: 6,84 0,61
                      QtCurve: 2,47 0,07
                      Raleigh: 1,61 0,07
                      ---
                      Plain TWM: 1,54 0,03

                      QGears COMPO (fps)
                      Oxygen: 273,224 3,358
                      CDE theme: 558,729 15,183

                      KDE 4.11 is not slower than any other DE, it's just the Oxygen theme that is quite CPU heavy. Users with weaker machines will probably want to use QtCurve instead. It's also worth noting that KWin in KDE 4.11 has improved VSync which could probably slow 2D rendering down as well if it's set incorrectly. I can't test this because VSync doesn't appear to be an issue on my GPU.

                      Comment


                      • #26
                        Originally posted by ACiD View Post
                        Unity is not usable on any pc simply because of its horrible design. It's like going Windows8
                        I see a lot of people comparing both unity and gnome 3 to windows 8, but they really aren't that similar.

                        The main problem with windows 8 is it has two entirely different interfaces and sets of application 'at war with each other', and it makes for a very inconsistant and annoying expereicne. Metro is basically its own DE with its own applications, and in windows 8 it is shoehorned as being the "start menu", and the integration with the classic desktop is half-assed.

                        Unity and gnome-shell are still unified interfaces that don't have this problem. If the unity dash or gnome-shell overlay had its own apps that could only run inside the dash, and the dash was fullscreen and its own environment then you could compare it to windows 8

                        Comment


                        • #27
                          Originally posted by bwat47 View Post
                          I see a lot of people comparing both unity and gnome 3 to windows 8, but they really aren't that similar.

                          The main problem with windows 8 is it has two entirely different interfaces and sets of application 'at war with each other', and it makes for a very inconsistant and annoying expereicne. Metro is basically its own DE with its own applications, and in windows 8 it is shoehorned as being the "start menu", and the integration with the classic desktop is half-assed.

                          Unity and gnome-shell are still unified interfaces that don't have this problem. If the unity dash or gnome-shell overlay had its own apps that could only run inside the dash, and the dash was fullscreen and its own environment then you could compare it to windows 8
                          I don't know which problem most people have, but I never used a metro app in my install, and I still find Windows 8 UI to be far inferior to Windows 7 for a desktop. And I believe (read as a belief, I have no polls to check if people agree) most people on desktop don't really care about Modern apps, and are annoyed by the Metro interface. Which is the common point with Unity/GNOME-shell, the touch optimized but not so for an actual desktop UI.

                          Comment


                          • #28
                            Ubuntu 13.10 Desktop Tests: Unity 7.1, KDE 4.11, Xfce 4.10, GNOME 3.8

                            In the end it always comes back to talk about Unity, this means that like it or not is crucial. I think Unity is one of the best Shell, I could not help it, dash and hud are fundamental for me. I am happy the tests and I hope that these Unity best ever.

                            Comment


                            • #29
                              Originally posted by mrugiero View Post
                              I don't know which problem most people have, but I never used a metro app in my install, and I still find Windows 8 UI to be far inferior to Windows 7 for a desktop. And I believe (read as a belief, I have no polls to check if people agree) most people on desktop don't really care about Modern apps, and are annoyed by the Metro interface. Which is the common point with Unity/GNOME-shell, the touch optimized but not so for an actual desktop UI.
                              I do tech support for an ISP, so I deal with lots of average users. Most people could grasp the basics of the windows 7 interface alright, but everyone I've talked to that uses windows 8 gets utterly confused with the whole "switching between metro and classic desktop" thing, and not the metro interface itself. Having two totally different interfaces that get switched between often is very confusing and inconsistent. Another big issue metro has that gnome-shell or unity don't have is the fact that all [metro] apps are forced to run fullscreen, and can only be run from within the start screen (zero integration with the desktop) which annoys many people. With unity and gnome-shell you still run familiar windowed apps, that all run in the same environment and everything is well integrated. There is no bizarre switching between two totally different desktop interfaces, and having apps that only run in a certain "special" interface or any nonsense like that with gnome 3 or unity.

                              I also wish people would stop saying unity and gnome-shell are "touch optimized" and not desktop optimized. Unity 7 is totally desktop optimized and not very touch friendly at all. have you ever tried to use unity on a touchscreen? Unity is a hell of a lot more keyboard and mouse friendly than touch friendly. The upcoming unity 8 will be far more touch optimized though, but the plan is for unity 8 to have a 'desktop mode' that works like unity 7 afiak so it should work as well on the desktop as unity 7 does, and as I mentioned I certainly wouldn't call unity 7 "touch optimized". Gnome-shell isn't very good on touchscreens yet either (although it is something they are working on), and like unity gnome-shell is very keyboard friendly and right now its a lot more 'desktop friendly' than 'touch friendly'. I use gnome-shell on my laptop and I like it much better than windows 8. I ran windows 8 for a few months on my gaming desktop but ended up going back to windows 7.
                              Last edited by bwat47; 08-31-2013, 06:09 PM.

                              Comment


                              • #30
                                Originally posted by bwat47 View Post
                                I see a lot of people comparing both unity and gnome 3 to windows 8, but they really aren't that similar.

                                The main problem with windows 8 is it has two entirely different interfaces and sets of application 'at war with each other', and it makes for a very inconsistant and annoying expereicne. Metro is basically its own DE with its own applications, and in windows 8 it is shoehorned as being the "start menu", and the integration with the classic desktop is half-assed.

                                Unity and gnome-shell are still unified interfaces that don't have this problem. If the unity dash or gnome-shell overlay had its own apps that could only run inside the dash, and the dash was fullscreen and its own environment then you could compare it to windows 8
                                To me, Unity resembles OS X more than Windows 8. A very very buggy and inconsistent and ugly version of OS X.

                                Comment

                                Working...
                                X