*** This bug is a duplicate of bug 129142 ***
https://bugs.launchpad.net/bugs/129142
** This bug has been marked a duplicate of bug 129142
Really Slick Screensavers use 100% CPU
--
screensavers cause high CPU usage
https://bugs.launchpad.net/bugs/174191
You received this bug notification
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.
** Attachment added:
"rss-glx_0.8.1-8ubuntu4_fix_fps_limiter_and_set_default_fps.
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 rep
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 3
well, I ran the first one...LOL, it ran for 2 hours and I just now
killed the prossesgrrr. 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 fr
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; do
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;
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 7
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
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
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
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 balan
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
--
screensavers cause high CPU usage
https://bugs.launchpad.net/bugs/174191
You received this bug notification b
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
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
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 mentio
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 d
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
hu, 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 h
> 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
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)
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
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.
--
screensavers cause high CPU usage
https://bugs.launchpad.net/bugs/174191
You received this bug notification because y
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 %MEMVSZ RSS TTY STAT START TIME COMMAND
-
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
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 co
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
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 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 th
29 matches
Mail list logo
