- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Are Your Desktop Effects Slowing You Down?
|
|
|
Comments (7)
This confirms something I have long believed was the case during my trials of successive versions of KDE4. I found if you turned off all desktop effects you got a desktop speed that began to approach that of KDE3.5 . Choose and lose I guess, where desktop effects are concerned.
Hooo boy Ridcully, I'm going to have some fun here. :)
You obviously did not actually look at the article. Maybe you did, but did you actually SEE what was in it? You will notice that the benchmark difference for the KDE effects was not that much at all between when it was on or off, whereas the Compiz benchmark showed a bigger difference in speed.
Furthermore, the article was not about desktop speed, but about 3D performance. So, even if you are correct about KDE effects slowing it down, this article did not go an inch towards providing "confirmation at last".
You obviously did not actually look at the article. Maybe you did, but did you actually SEE what was in it? You will notice that the benchmark difference for the KDE effects was not that much at all between when it was on or off, whereas the Compiz benchmark showed a bigger difference in speed.
Quoting:Across all three benchmarks having Compiz enabled on the system caused a 10.7% performance decrease, while Kwin only caused a 1% decrease.
Furthermore, the article was not about desktop speed, but about 3D performance. So, even if you are correct about KDE effects slowing it down, this article did not go an inch towards providing "confirmation at last".
Actually Jacog, I saw that point while reading the article and you are dead right...no argument; the results for Compiz are far nastier than Kwin. However, what I wrote was what I personally found on my hardware, and believe me, it's pretty modern dual core stuff and it has been consistent from version to version of KDE4. It was just nice to see my results confirmed elsewhere, even if not as dramatic as the ones I got on my setup.
I was tempted to go back and modify the original post...........and then I thought.......naaah......I am sure Jacog will enjoy "getting to me".........so I didn't. No worries. :-)
I was tempted to go back and modify the original post...........and then I thought.......naaah......I am sure Jacog will enjoy "getting to me".........so I didn't. No worries. :-)
Well, as I said, you are not necessarily wrong about desktop performance. It does vary greatly between systems. Just saying that the article didn't actually measure that.
Accepted in full Jacog.......serves me right for posting in a hurry......I was hastening to a Dr's appt. Mitigating circumstances, but I do plead guilty as charged. Oh well, to err is human, and I sure as heck ain't divine !!!!!!
I apologize in advance for the long diatribe,... but SOME of it is worth the read...
A point to bring up in terms of composite desktops in Linux is that, unlike Windoze "Aero-glass," compositing in Linux usually off-loads computing resources from the CPU to the GPU, rather than tax it further (but obvioulsy, this is not true of ALL effects, otherwise you wouldn't see a CPU spike at all).
If you want a true test of how much the compositing is off-loading to the GPU, you should either run with compositing turned on, but no-to-little effects versus with compositing turned off, or compare compositing effects in hardware supported OpenGl as opposed to running them with software Vesa driver with Mesa OpenGL, or run with OpenGL turned off completey versus turned on, but still with your correct hardware drivers. After all, with a lot of effects turned on, you are actually asking the WM to do more stuff... If the WM isn't all that efficeint in off-loading its compositing jobs, that's when you will see desktop performance degrade.
Whether or not the desktop is more "responsive" is another story, and is heavily influenced by what you are doing, and what particular effects you have turned on,... But what you generally end up with is more CPU resources available for actual COMPUTING as opposed to needing a small supercomputer to even have the effects turned on, as you do with the competing OS.
I have noticed this on my (3) netbooks. With compositing turned on (yes Compiz), menus respond faster, the CPU gets tied up less long when doing bigger jobs, moving windows is more reponsive (if Wobbly Windows are turned off, that is), the windows redraw faster, etc. Using a CPU load counter, with compositing turned off and trying to move or manipulate a window, you will often see a big inital CPU spike. With compositing turned on, but with minimal effects, you do not see as large a CPU spike when doing the same thing. But that's anecdotal experience from my perceptions...
If you have had a different experience, let me know. And before you finalize your conclusions, try reducing swappiness on your desktop machine to something like 10 versus 60 or 100, which many distros use out of box. Unless you reduce swappiness, you might not be measuring type of performance drag that you think you are. You might, instead, be measuring the tendency of your desktop to push textures into swap space and out again versus really measuring deskop performance of the compositing manager. This is particularly true with "shared memory" GPU chipsets, versus ones with their own RAM.
I think the big thrust of the article was that when you are using a compositing manager, it "steals" GPU resources away from OTHER apps that want to use OpenGL (i.e.: games, mostly). that is to be expected, to some degree. As the big WMs (Gnome, etc.) start using more internal compositing, rather than Compiz, I think we will see results more like the KDE results. Plus if you are an older user, and doing less gaming, you will be more inclined to want a prettier work desktop than to be able to run Alien Arena, or whatever, at a higher FPS count.
A point to bring up in terms of composite desktops in Linux is that, unlike Windoze "Aero-glass," compositing in Linux usually off-loads computing resources from the CPU to the GPU, rather than tax it further (but obvioulsy, this is not true of ALL effects, otherwise you wouldn't see a CPU spike at all).
If you want a true test of how much the compositing is off-loading to the GPU, you should either run with compositing turned on, but no-to-little effects versus with compositing turned off, or compare compositing effects in hardware supported OpenGl as opposed to running them with software Vesa driver with Mesa OpenGL, or run with OpenGL turned off completey versus turned on, but still with your correct hardware drivers. After all, with a lot of effects turned on, you are actually asking the WM to do more stuff... If the WM isn't all that efficeint in off-loading its compositing jobs, that's when you will see desktop performance degrade.
Whether or not the desktop is more "responsive" is another story, and is heavily influenced by what you are doing, and what particular effects you have turned on,... But what you generally end up with is more CPU resources available for actual COMPUTING as opposed to needing a small supercomputer to even have the effects turned on, as you do with the competing OS.
I have noticed this on my (3) netbooks. With compositing turned on (yes Compiz), menus respond faster, the CPU gets tied up less long when doing bigger jobs, moving windows is more reponsive (if Wobbly Windows are turned off, that is), the windows redraw faster, etc. Using a CPU load counter, with compositing turned off and trying to move or manipulate a window, you will often see a big inital CPU spike. With compositing turned on, but with minimal effects, you do not see as large a CPU spike when doing the same thing. But that's anecdotal experience from my perceptions...
If you have had a different experience, let me know. And before you finalize your conclusions, try reducing swappiness on your desktop machine to something like 10 versus 60 or 100, which many distros use out of box. Unless you reduce swappiness, you might not be measuring type of performance drag that you think you are. You might, instead, be measuring the tendency of your desktop to push textures into swap space and out again versus really measuring deskop performance of the compositing manager. This is particularly true with "shared memory" GPU chipsets, versus ones with their own RAM.
I think the big thrust of the article was that when you are using a compositing manager, it "steals" GPU resources away from OTHER apps that want to use OpenGL (i.e.: games, mostly). that is to be expected, to some degree. As the big WMs (Gnome, etc.) start using more internal compositing, rather than Compiz, I think we will see results more like the KDE results. Plus if you are an older user, and doing less gaming, you will be more inclined to want a prettier work desktop than to be able to run Alien Arena, or whatever, at a higher FPS count.
Here I thought it was going to be about how spending all that time worrying (in the sense of fiddling with, not in the sense of being scared about) the desktop effects and waiting for them to execute was going to slow down work-flow.
How's that for not reading the article?
How's that for not reading the article?
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post