Originally posted by ACiD
View Post
Announcement
Collapse
No announcement yet.
Ubuntu 13.10 Desktop Tests: Unity 7.1, KDE 4.11, Xfce 4.10, GNOME 3.8
Collapse
X
-
Originally posted by varikonniemi View PostI'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.
* http://userbase.kde.org/Desktop_Effe...raphics_System
Comment
-
Originally posted by droste View PostGive 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
-
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
-
Originally posted by StephanG View PostWhat 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).
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; 31 August 2013, 09:00 AM.
Comment
-
Originally posted by chrisb View PostSomething is seriously wrong with GtkPerf on KDE..
Comment
-
Originally posted by StephanG View PostWhy 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?
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.
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
Comment