In summary:

The Debian package of xscreensaver currently excludes many savers from the default install, on the basis of them using too much CPU.  This is no longer the case.  As those savers no longer use too much CPU, the justification for excluding them from the default install no longer exists, and they should be installed by default.


Longer version:

Currently, Debian divides xscreensaver into five packages:

xscreensaver (base)
xscreensaver-data (non-OpenGL screen savers, part 1)
xscreensaver-data-extra (non-OpenGL screen savers, part 2)
xscreensaver-gl (OpenGL screen savers, part 1)
xscreensaver-gl-extra (OpenGL screen savers, part 2)

The choice of which savers to put in the "part 2" packages instead of the "part 1" packages was made by Jose Luis Rivas Contreras <ghostbar38@gmail.com> and Tormod Volden <debian.tormod@gmail.com> back in 2007 or 2008 by running each of the screen savers and timing their CPU usage, and putting those with high CPU usage in the "part 2" packages, not installed by default.

I believe these are the tests they ran, years ago: https://wiki.ubuntu.com/X/Screensavers

It has always been my goal with xscreensaver that *no* screen saver should use significant CPU when running.  Since he ran his tests, I have fixed those savers that were using too much CPU (mostly by adjusting their default settings to be gentler).

It is my belief that currently, none of the screen savers included with xscreensaver use significant CPU when running with their default options.

Therefore, it is my belief that the -extra packages are unnecessary, and their contents should be folded in to the -data and -gl packages, reducing the number of xscreensaver packages from 5 to 3. I would like this to happen so that the default is to install the *complete* xscreensaver package instead of just an arbitrary subset of it.  Since most users will just take the defaults, they won't even know that the "part 2" savers exist, and many of them are pretty cool!  And the justification for excluding them no longer exists.

Over the past 3 years, I have repeatedly asked Jose to re-run the tests he ran by which he decided which savers to push into the "extras" package, and let me know if he still sees any savers using excessive CPU (because I don't believe there are any, but if there are, I would like to fix that bug.)

I'm sorry to say that he has never responded.

In fact, I haven't gotten any mail from him at all since September 2008, so even though he is still listed as the Debian maintainer of xscreensaver, I'm not sure he is still paying attention.

So -- if there is anyone reading this who considers themselves to be in charge of the Debian xscreensaver package, please reconsider the split between the "default" and "extras" packages, because I believe it to be based on old data and on assumptions which are no longer true.

Thanks...

Hello Jamie, I'm going to check these tonight at home. ;-)

I don't like neither the extra split but too much users were complaining.

Regards
-----Original Message-----
From: Jamie Zawinski <jwz@jwz.org>
Date: Wed, 15 Sep 2010 02:25:52
To: <submit@bugs.debian.org>
Reply-To: Jamie Zawinski <jwz@jwz.org>, 596944@bugs.debian.org
Subject: Bug#596944: please reconsider xscreensaver *-extra package split

Package: xscreensaver
Version: 5.05-3


In summary:

The Debian package of xscreensaver currently excludes many savers from the default install, on the basis of them using too much CPU.  This is no longer the case.  As those savers no longer use too much CPU, the justification for excluding them from the default install no longer exists, and they should be installed by default.


Longer version:

Currently, Debian divides xscreensaver into five packages:

xscreensaver (base)
xscreensaver-data (non-OpenGL screen savers, part 1)
xscreensaver-data-extra (non-OpenGL screen savers, part 2)
xscreensaver-gl (OpenGL screen savers, part 1)
xscreensaver-gl-extra (OpenGL screen savers, part 2)

The choice of which savers to put in the "part 2" packages instead of the "part 1" packages was made by Jose Luis Rivas Contreras <ghostbar38@gmail.com> and Tormod Volden <debian.tormod@gmail.com> back in 2007 or 2008 by running each of the screen savers and timing their CPU usage, and putting those with high CPU usage in the "part 2" packages, not installed by default.

I believe these are the tests they ran, years ago: https://wiki.ubuntu.com/X/Screensavers

It has always been my goal with xscreensaver that *no* screen saver should use significant CPU when running.  Since he ran his tests, I have fixed those savers that were using too much CPU (mostly by adjusting their default settings to be gentler).

It is my belief that currently, none of the screen savers included with xscreensaver use significant CPU when running with their default options.

Therefore, it is my belief that the -extra packages are unnecessary, and their contents should be folded in to the -data and -gl packages, reducing the number of xscreensaver packages from 5 to 3. I would like this to happen so that the default is to install the *complete* xscreensaver package instead of just an arbitrary subset of it.  Since most users will just take the defaults, they won't even know that the "part 2" savers exist, and many of them are pretty cool!  And the justification for excluding them no longer exists.

Over the past 3 years, I have repeatedly asked Jose to re-run the tests he ran by which he decided which savers to push into the "extras" package, and let me know if he still sees any savers using excessive CPU (because I don't believe there are any, but if there are, I would like to fix that bug.)

I'm sorry to say that he has never responded.

In fact, I haven't gotten any mail from him at all since September 2008, so even though he is still listed as the Debian maintainer of xscreensaver, I'm not sure he is still paying attention.

So -- if there is anyone reading this who considers themselves to be in charge of the Debian xscreensaver package, please reconsider the split between the "default" and "extras" packages, because I believe it to be based on old data and on assumptions which are no longer true.

Thanks...

Yes, but I have occasionally been running more tests since then, so I
know it is still a problem. I need to update that page though.

Note that the high CPU usage is often (always) due to lack of
functionality in the graphic card drivers, and not to bugs in
xscreensaver. We rely on our own testing on different hardware and of
reported bugs about high CPU usage. This has not been very systematic
but as often in distribution packaging, a compromise between time
invested and getting "most" things to work for "most" people.

Since we are providing a Linux distribution, the end user experience
is what counts. We can not play the blame game ("notourbug") and tell
people to fix their graphics drivers. And yes, I try to fix graphics
drivers also, at least by doing some xorg related QA work and smaller
patches.

Yes, the package complexity is not nice for anyone, and it is sad when
some users don't know they can try out all hacks by installing the
extra packages. I would even have liked to see the package count down
to 2 since everybody has GL libraries installed, at least if some
detection of HW acceleration could be done run-time.

However we haven't come up with a better mechanism for us or the
consumers (whether users, system administrators or downstream
packagers) to select which hacks to run by default. Most consumers of
the hacks do not even run the xscreensaver engine and its preferences
dialog. The treatment of the xscreensaver package certainly is made
more complicated by the fact that parts of it are used by other
screensaver engines. Which you probably have mixed feelings about :)

Jamie, I have the impression you are reading some of the xscreensaver
bug mail, so you have certainly seen that Jose is actively maintaining
it together with me. So please no theater. On the other hand it is
better that you route your requests through the bug tracker like you
are doing this time, or to the package maintainer list (which I fail
to remember the address of here and now) rather than sending him
private e-mail. None of us are working full time on this, and in busy
times some things slip through the cracks.

We are continuously reconsidering the split (ever since before we made
it), but we would need an alternative solution to the issues it
addresses. Until the day all hacks run nicely on almost all hardware.

Thanks for bringing it up again. It is time we do a new round of
benchmarks. Unfortunately I haven't had much success in getting other
people to contribute benchmark results yet.

And your suggestions are truly welcome. We are just packagers, and
would like to help to get your software in the hands of all users that
can profit from it, and so that it works without any hassle for them.
The less clutter and magic we have in our debian/ directory, the
happier we will be.

Tormod

Tormod from the checks I made I believe we could just drop the split.

-----Original Message-----
From: Tormod Volden <debian.tormod@gmail.com>
Date: Fri, 17 Sep 2010 14:27:49
To: Jamie Zawinski<jwz@jwz.org>; <596944@bugs.debian.org>
Reply-To: Tormod Volden <debian.tormod@gmail.com>, 596944@bugs.debian.org


Yes, but I have occasionally been running more tests since then, so I
know it is still a problem. I need to update that page though.

Note that the high CPU usage is often (always) due to lack of
functionality in the graphic card drivers, and not to bugs in
xscreensaver. We rely on our own testing on different hardware and of
reported bugs about high CPU usage. This has not been very systematic
but as often in distribution packaging, a compromise between time
invested and getting "most" things to work for "most" people.

Since we are providing a Linux distribution, the end user experience
is what counts. We can not play the blame game ("notourbug") and tell
people to fix their graphics drivers. And yes, I try to fix graphics
drivers also, at least by doing some xorg related QA work and smaller
patches.

Yes, the package complexity is not nice for anyone, and it is sad when
some users don't know they can try out all hacks by installing the
extra packages. I would even have liked to see the package count down
to 2 since everybody has GL libraries installed, at least if some
detection of HW acceleration could be done run-time.

However we haven't come up with a better mechanism for us or the
consumers (whether users, system administrators or downstream
packagers) to select which hacks to run by default. Most consumers of
the hacks do not even run the xscreensaver engine and its preferences
dialog. The treatment of the xscreensaver package certainly is made
more complicated by the fact that parts of it are used by other
screensaver engines. Which you probably have mixed feelings about :)

Jamie, I have the impression you are reading some of the xscreensaver
bug mail, so you have certainly seen that Jose is actively maintaining
it together with me. So please no theater. On the other hand it is
better that you route your requests through the bug tracker like you
are doing this time, or to the package maintainer list (which I fail
to remember the address of here and now) rather than sending him
private e-mail. None of us are working full time on this, and in busy
times some things slip through the cracks.

We are continuously reconsidering the split (ever since before we made
it), but we would need an alternative solution to the issues it
addresses. Until the day all hacks run nicely on almost all hardware.

Thanks for bringing it up again. It is time we do a new round of
benchmarks. Unfortunately I haven't had much success in getting other
people to contribute benchmark results yet.

And your suggestions are truly welcome. We are just packagers, and
would like to help to get your software in the hands of all users that
can profit from it, and so that it works without any hassle for them.
The less clutter and magic we have in our debian/ directory, the
happier we will be.

Tormod

Jose, can you post your results here? I ran tests now (from a Ubuntu
10.10 beta live CD I had at hand, the graphics stack is pretty much
the same as in Debian unstable) and updated the wiki page referenced
above. It does not look so good.

As I said, if any of the screen savers exhibit high CPU in their default
configuration, then I consider this a bug in the saver.  The only way this
is going to get fixed is if you report it to me (or submit a patch with
appropriately-scaled-back default timings.)

The one (large) exception to this is the OpenGL savers -- obviously
those are going to be a problem on any machine that does not have
working 3D acceleration.  But, on such a system, *all* of the
OpenGL savers will be equally problematic, so uninstalling
xscreensaver-gl is presumably the right fix; no need for -gl-extra.

Fair enough, but I would like to fix the problems that lead to
degraded user experience rather than just throwing the
screen savers out with the bathwater...