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.
Why are many benchamarks capped around 60fps? Are you doing benchmarks with vsync on? There is something wrong
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).
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.
Apparently it does cause a noticeable impact on some apps (Bug #280000 Laggy and slow scroll on Inkscape docked dialogs).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