Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 46

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

  1. #11
    Join Date
    Oct 2011
    Posts
    67

    Default

    Quote 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"?

  2. #12
    Join Date
    Feb 2013
    Posts
    438

    Default

    Quote Originally Posted by Honton View Post
    KDE 4.11 is slow.

    Something is seriously wrong with GtkPerf on KDE..

  3. #13
    Join Date
    Jul 2012
    Posts
    755

    Default

    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.

  4. #14
    Join Date
    Jul 2009
    Location
    Germany
    Posts
    492

    Default

    Quote 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

  5. #15
    Join Date
    Aug 2012
    Posts
    8

    Default

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

  6. #16
    Join Date
    Jul 2012
    Posts
    755

    Default

    Quote 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.

  7. #17
    Join Date
    Jul 2011
    Posts
    24

    Default

    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).

  8. #18
    Join Date
    Jun 2013
    Posts
    219

    Default

    Quote 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 at 09:00 AM.

  9. #19
    Join Date
    Apr 2010
    Posts
    734

    Default

    Quote 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?

  10. #20
    Join Date
    Feb 2013
    Posts
    438

    Default

    Quote 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •