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

  • #11
    Originally posted by ACiD View Post
    Unity is not usable on any pc simply because of its horrible design. It's like going Windows8
    Go troll somewhere else. Is your vision impaired? They don't look the same and don't work alike. So what exactly is "like Windows 8"?

    Comment


    • #12
      Originally posted by Honton View Post
      KDE 4.11 is slow.

      Something is seriously wrong with GtkPerf on KDE..

      Comment


      • #13
        Glad that this might finally shut up all these annoying folks who spread this bullshit that XFCE and LXDE make your games magically run faster than Unity & Co. because they use less RAM.

        Comment


        • #14
          Originally posted by varikonniemi View Post
          I'm a bit surprised how shit KDE is since that was the DE i was thinking to try next. I guess i will wait for framework5 and see if their new generation of qt magic is up to par with the competition.
          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

          Comment


          • #15
            Why are many benchamarks capped around 60fps? Are you doing benchmarks with vsync on? There is something wrong

            Comment


            • #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

                      Working...
                      X