screensavers cause high CPU usage

I first wanted to say that I've also seen that behaviour.

Now, I'd also like to point out that the second part of your bug isn't strictly true. I believe that the default settings blank out the screen after a certain amount of time (I think it's either 30 minutes or an hour), so after that time the screensaver will stop draining CPU. However, having high CPU usage during idle time is not something desirable on laptops, so it might be interesting to modify the default blank out time if a laptop is detected.

Finally, three possible workarounds if you want to have screensavers and still have low CPU usage:
1) Select a specific non-draining screensaver/blank screen (doh!)
2) Substitute gnome-screensaver with xscreensaver. The added configurability might also help (doh! number one revisited)
3) Uninstall rss-glx. This will remove the 3D screensavers, which are usually the life-draining ones. (doh! This Miguel guy doesn't look really bright)

Actually you may very well be correct on my second part of the problem. However I am not sure why that makes it less a bug because it only lasts for 30 minutes before it goes to sleep ? why on earth would an application designed to be "green" friendly race the CPU until it goes to sleep ?

Second, I already know that I need to select a more PC friendly screen saver, thats why I have reported the bug (doh ! ) ( :P ), however the less curious people that are just now switching to linux will have no clue that the screen saver they selected is racing the CPU unless the have learned the TOP command or know that a CPU system monitor is available AND that it is not normal for a CPU to race when NOT being used. - most people don't know that %100 CPU is not good, and most people would not know that it is happening either.

3rd, hummm, while I have been using Ubuntu for 3+ years now, I have never been able to get xscreensave to work, I have no desire to be a linux guru, or expert, just skilled enough to configure use, minor repairs, etc. My first choice for a screensaver is ElectricSheep, thats the only screen saver I want and it requires xscreensaver, and I have never been able to get it to work even though its in the repo, which leads to a second problem, if its in the repo, then it should work, but after doing much research, it looks like the only people that are capable of making ElectricSheep work on a Gnome system are the Linux gurus.

4th, I have no clue what rss-glx is, but once again, why would removing this fix the 100% CPU racing problem ? it will still be there in the code will it not ? it will just remove the problem from my computer if you are correct, but the bug will still exist in the code. (doh again ! )

So, just to be clear, I am trying to report a bug in the bug reporting forum, not find a work around to a problem....... :) but thanks for confirming the problem , hehehe,

It would be good if we can do some benchmarking of the screensaver hacks. Some hacks use a lot of CPU on some computers because the 3D acceleration partially fails on specific graphic cards and falls back to software rendering. This is in many cases a bug in the drivers and should be identified and fixed.

Can you all please have a look at the tests on https://wiki.ubuntu.com/X/Screensavers ? Test results, improvements and comments are welcome, just add them to the wiki page.

I would be the very last person on earth to contradict anyone who has Linux expertise as I have so little that I'm just not going to go there.....however, I have been using Ubuntu since 5.04 and I use only Nvidia cards, and not one single release since 5.04 had good drivers then according to the comment above about it being a driver issue. I have multiple computers with Nvidia cards ranging from NV17 all the way thru NV41 including an Nvidia XFX Geforce 7950 GT. I have used every single driver offered restricted or otherwise including what Envy offers and not one driver then works according to this logic. Rest assured, I thought long and hard about this post, but I just can't agree with the statement that its a driver failure because it is suggested that some cards/drivers work, and others don't. I have no issues at all running any other application that requires acceleration including GoogleEarth, Beryl, Compiz, compiz fuzion, and numerous 3D games on various machines all of witch have Nvidia restricted drivers installed. but for some reason the drivers are failing to render acceleration for the screensavers only ? thats just way too much a jump for me to accept. I can accept that acceleration is failing by looking at CPU usage, yes, but not due to a driver bug, I think it far more likely that the implementation that calls for acceleration in the screensaver is failing. Maybe I'm wrong, won't be the first time, but if acceleration works everywhere else, it just makes no sense to me why it breaks suddenly when its a screensaver being accelerated.

I said "in many cases", not all, it's a driver problem. But without test results on a large number of different cards, it's hard to tell. From the few test results on the wiki page (please keep bringing them on) it seems like some screensavers use a lot of CPU on all different cards, in which case we will certainly remove them from the standard selection.

There are many bits in graphic acceleration support, some hacks might try some obscure ones that are not used in the mainstream applications.

I move this to the xscreensaver package since most screensaver hacks comes from the xscreensaver package, even though they are used by gnome-screensaver.

I could not figure out how to add my results to that link. I could not run full screen because the full screen locked up requiring power off, no keyboard or mouse.

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
------------------------------------------------------------------------------
gene 6062 0.6 0.2 39132 5744 pts/0 S 21:54 0:00 /usr/lib/xscreensaver/abstractile
gene 6066 3.2 0.3 60400 7804 pts/0 SL 21:54 0:00 /usr/lib/xscreensaver/antinspect
gene 6071 3.0 0.4 61884 9564 pts/0 SL 21:55 0:00 /usr/lib/xscreensaver/antspotlight
gene 6077 2.0 0.4 83212 9196 pts/0 RL 21:55 0:00 /usr/lib/xscreensaver/atunnel
gene 6087 2.4 0.4 61860 8752 pts/0 SL 21:56 0:00 /usr/lib/xscreensaver/blinkbox
gene 6108 2.3 0.3 60652 7820 pts/0 RL 21:59 0:00 /usr/lib/xscreensaver/cubestorm
gene 6113 2.6 0.0 30884 1776 pts/0 R 21:59 0:00 /usr/lib/xscreensaver/cwaves
gene 6122 0.0 0.0 30884 1724 pts/0 S 22:00 0:00 /usr/lib/xscreensaver/deco
gene 6126 1.6 0.2 33440 4148 pts/0 R 22:01 0:00 /usr/lib/xscreensaver/distort
gene 6194 2.9 0.3 60832 8168 pts/0 SL 22:08 0:00 /usr/lib/xscreensaver/gears
gene 6240 1.1 0.3 66988 8108 pts/0 RL 22:12 0:00 /usr/lib/xscreensaver/glsnake
gene 6326 2.1 0.3 60460 7680 pts/0 RL 22:21 0:00 /usr/lib/xscreensaver/morph3d
gene 6330 0.2 0.0 31028 1772 pts/0 S 22:22 0:00 /usr/lib/xscreensaver/penrose
gene 6335 1.2 0.4 61444 8660 pts/0 SL 22:22 0:00 /usr/lib/xscreensaver/pipes
gene 6348 0.7 0.3 60672 7872 pts/0 SL 22:24 0:00 /usr/lib/xscreensaver/polytopes
gene 6353 0.2 0.0 30884 1720 pts/0 S 22:24 0:00 /usr/lib/xscreensaver/popsquares
gene 6357 1.2 0.3 78608 8024 pts/0 SL 22:25 0:00 /usr/lib/xscreensaver/pulsar
gene 6371 1.8 0.1 32020 2916 pts/0 R 22:26 0:00 /usr/lib/xscreensaver/shadebobs
gene 6384 0.0 0.0 30884 1752 pts/0 S 22:28 0:00 /usr/lib/xscreensaver/slidescreen
gene 6395 0.1 0.0 37272 1916 pts/0 S 22:29 0:00 /usr/lib/xscreensaver/sonar
gene 6426 2.4 0.1 32020 3036 pts/0 R 22:32 0:00 /usr/lib/xscreensaver/swirl
gene 6100 4.6 0.4 67072 8264 pts/0 SL 21:58 0:01 /usr/lib/xscreensaver/circuit
gene 6132 6.3 0.4 61004 8608 pts/0 RL 22:01 0:01 /usr/lib/xscreensaver/endgame
gene 6137 4.1 0.4 67228 8444 pts/0 SL 22:02 0:01 /usr/lib/xscreensaver/engine
gene 6157 4.9 0.3 60396 7668 pts/0 SL 22:04 0:01 /usr/lib/xscreensaver/flipflop
gene 6161 4.6 0.4 61844 9368 pts/0 SL 22:04 0:01 /usr/lib/xscreensaver/flipscreen3d
gene 6181 3.8 0.4 83956 9760 pts/0 SL 22:06 0:01 /usr/lib/xscreensaver/flyingtoasters
gene 6190 5.6 0.1 31232 2076 pts/0 R 22:07 0:01 /usr/lib/xscreensaver/galaxy
gene 6199 6.4 0.3 60428 7688 pts/0 SL 22:08 0:01 /usr/lib/xscreensaver/gflux
gene 6207 4.6 0.4 61324 8688 pts/0 SL 22:09 0:01 /usr/lib/xscreensaver/glcells
gene 6...

Gene, many of the worst offenders in your list are not installed by default. Please uninstall "xscreensaver-gl-extra" and "xscreensaver-data-extra" if you have them installed.

Thormod,
I really do not believe that I installed the packages you want me to uninstall.....actually, I just did a search in synaptic and see that neither one of the packages you want me to uninstall are installed. I'm not trying to contradict you, but there is nothing for me to uninstall at the moment.......now it is possible that I ran the batch test above on another machine, but I would not have a clue which one...so, the machine I am currently on does not have the packages you mention, yet I still experience the CPU issue with the screensavers that ship default. my first action on any new install is to select one of the low CPU screensavers as my default to prevent CPU burn out.

wow, that was a mistake, I just installed the 2 packages mentioned above and half locked the computer requiring a hard reset. IMO they should be removed from the repo until they do not present this condition. but thats just my opinion. this test was preformed on a dual-cpu 2.0 ghtz (not dual-core) w/2 gig ram and a newer geforce fx card with the latest nvidia properity driver. this machine has raw power.

> my first action on any new install is to select one of the low CPU screensavers as my default to prevent CPU burn out.

As mentioned in the other bug, the default is "Blank screen"

Your computer locking because of the screensavers is really the fault of your proprietary graphics drivers. However I am not gonna say that they should be removed from the repository :) Well, they are not in the main repo, but only in the "restrictive" anyway. The collection of screensavers (especially the 3D ones) can be a real stress test for the drivers since they ask things from the card that for instance your text processor would not.

Of course we try to sort out which screensavers are performing bad in general, but if they only break with one, proprietary graphic driver, I guess it is the driver that should be fixed. Which we ourselves can not do, since they are made in secrecy by the same people who sold you the hardware. Maybe they have a bug tracker where you can report these problems? So unless Nvidia starts working with the open source community like Intel and ATI do, I can not see any good solution. We could maybe disable all screensavers when we detect the nvidia driver... But again, the default is blank screen anyway.

The nvidia driver specific crashes are submitted in bug #110125.

hummmm, I'm not sure I agree. As I stated above, I have seen this high CPU racing condition every since I started using Ubuntu 4 years ago. Its not something new. its there with each and every driver that Nvidia has released to the linux community. I do not agree that this is a driver issue as I have run the very same GPU on a windows computer in OGL mode and do not get the CPU racing issue. now before you go and say its a different platform, read further: there are several screensavers here in linux that I also run on one of my windows computer, I will list them later if needed, but not right now. I also have other OGL screensavers that I run in addition to directX on the windows platform. what I have seen is that ONLY the screensavers that I run common on both linux AND windows have the CPU racing problem. I do not have the CPU problem on my remaining windows OGL SS's, nor on my directX screensavers.

I would like to take a moment to say that I am a 20 year software engineer, I am not some typical user that does not know better. Nvidia releases linux drivers and windows drivers pretty much in sync with each other. the code base for the OGL linux drivers will not be that much different than it is for windows....which is what you are saying the problem is, the OGL code stream works for windows, I do not agree with you that its broke for linux. Since I have already shown that about a dozen of the screensavers are broke in both windows AND linux I wish you guys would at least look into the possibility that I am correct and stop blaming Nvidia or ati because you do not have access to source code. I have given enough reason to be suspicious of the screensavers to at least check the code that you do have access to.

Guys, I have all the respect in the world for the work you do here, but I'm using my Software Architect background and 20 years coding experience to ask you to show a little respect here. I do not have OGL driver issues on windows except when running the very same OGL screensavers that you guys do actually have access to. work what what you have.

If requested I can point you to the source code for the common OGL screensavers that I am referring to. ( at least I seem to recall that the source was free to d/l on the web site). In short, I just do not believe that each and every driver released by Nvidia over the last 4 years has the same problem over and over, but the problem does not exist in the windows code base. I also do not believe that its hardware related specific to my GPU's, I have about a dozen Nvidia GPU's, the problem exists for all Nvidia cards and ALL official drivers going back to my very first usage of Ubuntu.

I'm not trying to be disrespectful but my common sense and logic that has served me well over the last 2 decades would have to be failing me here if I accepted your explanation that its a driver issue. look at the screensavers that are failing on both windows and linux.

here is the web site that the screensavers I am talking about come from: http://www.reallyslick.com/. these are the very same screensavers that are offered in the Debian/Ubuntu repro as I run on windows. run these screensavers in windows and you get the very same CPU racing condition as you do here in Linux. But no other windows OGL screensaver has this issue. It just screams in my face that these dozen screensavers fail on 2 platforms and yet the blame seems to be placed on the drivers........

Oh yes, those screensavers are in the rss-glx package, which is also installed by default... I'll reassign to that package. I guess some of these are not really suited as screensaving in their default settings.

However if they are a problem both on WIndows and Linux which shares much of the same driver code, then the problem can really be this driver code, right? At least if these savers do not spin the CPU when used with other drivers and cards.

BTW, we should not mix to many things here, 100% CPU is another issue than lock-ups and crashes, although there's usually some correlation.

I'd like to take one minute to make sure that I am not giving out the wrong impression, I'm simply trying to get to the bottom of the 100% CPU racing condition on screensavers. I'm not knocking any code or anyones coding skills.

I am not reporting any lock-up issues here, I simply wanted to mention that when I installed the above mentioned extra savers, half caused a hard system lock...no mouse, no keyboard.

I am hoping to make sure that the linux savers do not burn out anyones CPU resulting from a weekend out of town at the beach while these savers are racing the CPU for 2 or 3 days at full 100% racing.

I am really wondering if hardware acceleration is happening with any of the OGL savers to include the common savers being discussed here.

This is my hope or wish: I'd like to see some nice savers that actually work but that do not place the CPU at risk of burn up. removing these nice savers will leave some really boring ugly savers. is hardware acceleration really being taken advantage of here ? can we get electricsheep installed by default in working condition to see if it works any better ?

I have tried to get Electricsheep installed but I have failed on each occation, I need help, may you all can get it working to see if its CPU friendly ???

I guess I simply cannot understand why OGL savers seem to be so CPU unfriendly ?? what can I do to help work this issue out ?

I just benchmarked the rss-glx screensavers on my ATI X1300 card as per https://wiki.ubuntu.com/X/Screensavers. Out of 19 savers, only 3 used less than 80% CPU... Maybe rss-glx should not be installed by default, even if they're really slick. From the upstream site, it seems they are optimized for slickness without thinking to much about resource usage.

However, many of the hacks have options that can be tuned for running more lightly. Please have a look at the man pages for each of them and experiment. We can add these options to the corresponding .desktop files.

below I copy and pasted an email that I received from the author of these screensavers, it turns out that this is expected behavior. however he said that there are options to help moderate this issue, but since we have no configuration dialog in the screensavers dialog, we can not do anything about the problem. maybe you can hard code some of the options by default. maybe going out and grabbing the very newest versions of his screensavors can help also, he says that he did some code cleanup on his site which helped somewhat. I seem to recall I did get better operation from the newest versions than I did from the older versions.

"Hi Gene,
I have a couple ideas to consider here; what you're seeing may be
expected behavior. I can see how you would argue that a CPU-eating
saver is a pretty bad idea. While writing those I have always aimed
at making eye candy even if it takes a lot of computation. I
definitely wasn't trying to write CPU savers.

First of all, when hardware acceleration isn't used I have always seen
framerates of 1FPS or worse. If you're seeing 10FPS or higher, you're
probably using hardware acceleration.

Some of my savers use a ton of compute power. Helios and Hyperspace
both compute implicit surfaces each frame. Skyrocket does quite a bit
of computation on default settings updating its particles. The other
savers use varying amounts of CPU and graphics power depending on your
settings, but they aren't usually as bad as the 3 I mentioned above.

To limit the frame rate (and possibly cut down CPU usage) I make a
couple recommendations on my website: "The easiest way is to enable
the "vertical sync" or "vsync" option in your graphics driver. This
will make the frame rate slow down to the monitor refresh rate. The
other way is to use the saver's internal frame rate limiter, which can
be accessed through its configuration dialog box." I don't know if
the rss-glx port included the frame rate limiter that I have built
into the original Windows versions

Does any of this information help, or is what you're seeing worse than
what I have described here? Feel free to copy this email to your bug
thread if you think it will help....
- Terry"

You don't need a configuration dialog to test out options, just check the options with e.g. "man lattice" and try them out like this:
 /usr/lib/xscreensaver/lattice --maxfps 12 --nice

yep !! that works( at least in a windowed setting, the real test is does it work in native full screen mode ? ), now how do I get that to do the same thing whenever a random SS starts ? where are these .desktop files you are referring to ? I will be happy to do some experiments to find a good balance of performance and eye candy/resource usage. matrixview is another SS that consumes resources and it works there too. I'll test settings for any SS that uses over 30% CPU and post results later when I have time. I did 5 savors so far in windowed mode with good results.

If you do "dpkg -L rss-glx" you'll see all the files in the package. Beware there are two .desktop files for each hack, the one used by the gnome-screensaver is the one in /usr/share/applications/screensavers/. It is the "Exec" line that you'll have to change, by adding your options to the already existing "-r" one.

ok, I just completed making adjustments to the .desktop files and I seem to have had success looking at the system resource monitor(the CPU usage )......grrr, but when I re-run the benchmark test as described in the wiki link above to compare old results with new results, it looks like the .desktop files are completely ignored for this benchmark.

"for s in /usr/lib/xscreensaver/*; do echo $s; $s & k=$! ; sleep 30; ps hu $k >> savers-cpu.log ; kill $k; wait; done"

how does that line need to be changed to benchmark the actual real world results of making changes to the .desktop files to make the benchmark use the new values that will actually be used while the screensavers are running ? I want to be able to post results of what affects my changes had so others can compare.......in short, I want to be able to compare apples to apples, not apples to oranges.

Yes, that benchmark works just like when running single savers from the command line unfortunately. I can modify it to squeeze out the Exec lines from the .desktop files instead, but it will still not be full screen mode. I have another method that forces the normal screensaver to cycle through the hacks and record their CPU usage, but I'll need to find my notes (rather than reinvent it).

ok, here are the values I used in the .desktop files that look like they produce CPU usage lower than 30%, but again, I was just doing visual monitoring, not actual CPU values:

gene 6417 68.4 0.3 39424 6492 pts/0 RL 22:31 0:20 /usr/lib/xscreensaver/sundancer2 - fixed -n <-
gene 6104 73.0 0.3 49376 7284 pts/0 RL 21:58 0:21 /usr/lib/xscreensaver/colorfire - fixed -n -x30
gene 6258 78.8 0.3 50228 8088 pts/0 RL 22:14 0:23 /usr/lib/xscreensaver/hufo_tunnel - fixed -n -x30
gene 6141 82.0 0.4 49924 8492 pts/0 RL 22:02 0:24 /usr/lib/xscreensaver/euphoria - fixed -n -x30
gene 6095 85.7 0.3 47292 7376 pts/0 RL 21:57 0:25 /usr/lib/xscreensaver/busyspheres - fixed -n -x30
gene 6253 84.3 0.3 47388 7268 pts/0 RL 22:14 0:25 /usr/lib/xscreensaver/hufo_smoke - fixed -n -x30
gene 6297 84.8 0.5 87092 10344 pts/0 RL 22:18 0:25 /usr/lib/xscreensaver/matrixview - fixed -n -x60 <-
gene 6339 86.4 0.5 52092 12088 pts/0 RL 22:23 0:25 /usr/lib/xscreensaver/plasma - fixed -n -x30
gene 6380 84.8 0.9 70780 19292 pts/0 RL 22:27 0:25 /usr/lib/xscreensaver/skyrocket - fixed -n -x30 sound does not work, might be pulse audio issue
gene 6082 88.0 0.3 47584 7312 pts/0 RL 21:56 0:26 /usr/lib/xscreensaver/biof - partial -n -x30 this one seems to have more than one impact
gene 6150 86.8 0.3 47232 6972 pts/0 RL 22:03 0:26 /usr/lib/xscreensaver/fieldlines - fixed -n -x30
gene 6168 88.8 0.3 47648 7328 pts/0 RL 22:05 0:26 /usr/lib/xscreensaver/flocks - fixed -n -x30
gene 6176 87.3 0.3 47628 7368 pts/0 RL 22:06 0:26 /usr/lib/xscreensaver/flux - fixed -n -x80 <-
gene 6249 87.5 0.6 55364 13828 pts/0 RL 22:13 0:26 /usr/lib/xscreensaver/helios - fixed -n -x30
gene 6262 87.8 1.6 87224 34028 pts/0 RL 22:15 0:26 /usr/lib/xscreensaver/hyperspace - fixed -n -x20 <-
gene 6276 87.0 0.3 50784 7920 pts/0 RL 22:16 0:26 /usr/lib/xscreensaver/lattice - fixed -n -x30
gene 6391 87.2 0.3 47244 7116 pts/0 RL 22:28 0:26 /usr/lib/xscreensaver/solarwinds - fixed -n -x30
gene 6408 89.8 0.3 48620 7076 pts/0 RL 22:30 0:26 /usr/lib/xscreensaver/spirographx - fixed -n -x30

I'll just wait till you can find your notes, but I'm pretty sure adding -nice and limiting -x to a framerate that the eye can see(or detect) (25 or 30 FPS) works.

This method is pretty "real world", but it will cycle through the savers at random so you need to let it run a long time before you have covered all the savers. First choose "Random" in the Screensaver preference. Then run this and do not touch the computer:

 gnome-screensaver-command --activate; while sleep 30; do ps ux --no-header | head -1 >> saver.log; gnome-screensaver-command --activate; gnome-screensaver-command --cycle; done

This should be more fool-proof (the previous one would often pick the wrong process):

P=`pgrep gnome-screensav`; gnome-screensaver-command --activate; while sleep 30; do ps lx | awk '{ if ($4=='$P') print}' >> saver.log; gnome-screensaver-command --activate; gnome-screensaver-command --cycle; done

You will have to sort the results with: sort -k 12 saver.log > random-savers.txt

well, I ran the first one...LOL, it ran for 2 hours and I just now killed the prosses....grrr. you said don't touch the keyboard or mouse so I followed directions and just let it run. (please don't tell me to follow you over the cliff - LOL ) no output in the log file, but got all kind of output from the terminal below. I'm trying the new version now.

*********** output format ********** *********** long options ***********
-o,o user-defined -f full --Group --User --pid --cols --ppid
-j,j job control s signal --group --user --sid --rows --info
-O,O preloaded -o v virtual memory --cumulative --format --deselect
-l,l long u user-oriented --sort --tty --forest --version
-F extra full X registers --heading --no-heading --context
                    ********* misc options *********
-V,V show version L list format codes f ASCII art forest
-m,m,-L,-T,H threads S children in sum -y change -l format
-M,Z security data c true command name -c scheduling class
-w,w wide output n numeric WCHAN,UID -H process hierarchy
ERROR: Unknown gnu long option.
********* simple selection ********* ********* selection by list *********
-A all processes -C by command name
-N negate selection -G by real group ID (supports names)
-a all w/ tty except session leaders -U by real user ID (supports names)
-d all except session leaders -g by session OR by effective group name
-e all processes -p by process ID
T all processes on this terminal -s processes in the sessions given
a all w/ tty, including other users -t by tty
g OBSOLETE -- DO NOT USE -u by effective user ID (supports names)
r only running processes U processes for specified users
x processes w/o controlling ttys t by tty
*********** output format ********** *********** long options ***********
-o,o user-defined -f full --Group --User --pid --cols --ppid
-j,j job control s signal --group --user --sid --rows --info
-O,O preloaded -o v virtual memory --cumulative --format --deselect
-l,l long u user-oriented --sort --tty --forest --version
-F extra full X registers --heading --no-heading --context
                    ********* misc options *********
-V,V show version L list format codes f ASCII art forest
-m,m,-L,-T,H threads S children in sum -y change -l format
-M,Z security data c true command name -c scheduling class
-w,w wide output n numeric WCHAN,UID -H process hierarchy
ERROR: Unknown gnu long option.
********* simple selection ********* ********* selection by list *********
-A all processes -C by command name
-N negate selection -G by real group ID (supports names)
-a all w/ tty except session leaders -U by real user ID (supports names)
-d all except session leaders -g by session OR by effective group name
-e all processes -p by process ID
T all processes on this terminal -s processes in the sessions given
a all w/ tty, including other users -t by tty
g OBS...

I cannot determine which column is the CPU usage in the new batch command. I have output, but don't see anything that resembles a % of 100. below are the results of the sort after running, it does not look like the batch ends itself, I had to ctrl+c to end the loop.

0 1000 8708 6464 30 10 36708 29904 - RNL ? 0:00 antspotlight -root
0 1000 8659 6464 30 10 21176 15744 - SNL ? 0:00 colorfire -r -n -x 30
0 1000 9179 6464 30 10 3556 1472 - SN ? 0:00 deco -root
0 1000 9004 6464 30 10 13700 4832 - SN ? 0:00 floaters /usr/share/pixmaps/ubuntu-screensaver.svg
0 1000 9283 6464 30 10 21184 15548 - RNL ? 0:00 flux -r -x 80 -n
0 1000 9652 6464 30 10 22176 16396 - RNL ? 0:00 glsnake -root
0 1000 8796 6464 30 10 21716 16100 - SNL ? 0:00 morph3d -root
0 1000 9261 6464 30 10 3568 1488 - SN ? 0:00 penrose -root
0 1000 9405 6464 30 10 22540 16836 - SNL ? 0:00 pipes -root
0 1000 9626 6464 30 10 21932 16304 - RNL ? 0:00 polytopes -root
0 1000 8742 6464 30 10 23368 16360 - SNL ? 0:00 pulsar -root
0 1000 9963 6464 30 10 23376 16364 - RNL ? 0:00 pulsar -root
0 1000 8783 6464 30 10 3556 1492 - SN ? 0:00 slidescreen -root
0 1000 8957 6464 30 10 3556 1496 - SN ? 0:00 slidescreen -root
0 1000 9566 6464 30 10 3556 1492 - SN ? 0:00 slidescreen -root
0 1000 9246 6464 30 10 28448 11532 - SNl ? 0:00 slideshow --location=/usr/share/pixmaps/backgrounds/cosmos
0 1000 9744 6464 30 10 28448 11536 - SNl ? 0:00 slideshow --location=/usr/share/pixmaps/backgrounds/cosmos
0 1000 8927 6464 30 10 3660 1592 - SN ? 0:00 sonar -root
0 1000 8994 6464 30 10 3660 1572 - SN ? 0:00 sonar -root
0 1000 10021 6464 30 10 19372 15088 - SNL ? 0:00 sundancer2 -r -n
0 1000 10046 6464 30 10 21924 16200 - SNL ? 0:01 cubestorm -root
0 1000 8813 6464 30 10 12352 10148 - SN ? 0:01 distort -root
0 1000 8676 6464 30 10 22180 16660 - RNL ? 0:01 engine -root
0 1000 8757 6464 30 10 25328 16196 - SNL ? 0:01 euphoria -r -n -x 30
0 1000 9846 6464 30 10 32596 27188 - SNL ? 0:01 flipscreen3d -root
0 1000 8537 6464 30 10 21184 15548 - SNL ? 0:01 flux -r -x 80 -n
0 1000 8731 6464 30 10 21184 15548 - RNL ? 0:01 flux -r -x 80 -n
0 1000 9167 6464 30 10 21180 15560 - SNL ? 0:01 flux -r -x 80 -n
0 1000 8875 6464 30 10 22224 16728 - SNL ? 0:01 gears -root
0 1000 8647 6464 30 10 21076 15672 - SNL ? 0:01 hufo_smoke -r -n -x 30
0 1000 9142 6464 30 10 21080 15676 - SNL ? 0:01 hufo_smoke -r -n -x 30
0 1000 9713 6464 30 10 11064 9008 - SN ? 0:01 swirl -root
0 1000 8606 6464 30 10 21672 16176 - SNL ? 0:02 antinspect -root
0 1...

Yes, the one-liner will just cycle through the savers at random until you stop it with ctrl-c. The CPU usage is displayed as before, in the second last column. If it shows 0:20 that's 20 seconds of CPU during the 30 seconds it run, = 67%.

Please attach your results and do not paste them in the report itself.

(When you tried the first one you must have made a typo. Use copy and paste. But use only the second one anyway.)

Here's patch for rss-glx 0.8.1 that enables frame limiter (50fps) by default and fixes frame limiter code. Also expands --max-fps and --nice parameters so they can used to disable frame limiter, not just turn it on.