XWHIRL(1) Rev. 0.1 XWHIRL(1)
3 August 1998
NAME
xwhirl - Screensaverlike animation of the X display
SYNTAX
xwhirl [ -hoscrmu ] [ -wn ][ -dp ]
DESCRIPTION
xwhirl animates your display by moving around a deformation
ressembling a blizzard. This gives the impression of a whirl bouncing
between the edges of the screen.
OPTIONS
Options will be parsed by getopt(3).Defaultoptionsaredetermined
setting them in the defaults.h file
-c Use clipmask when drawing. It is not very useful.
-dp Give a diameter for the size of the animated region different
from the default diameter. p is to be understood in pixels.
-D Print default (compiled in) parameter settings and exit.
-h Print information on available options.
-f Use an efficient algorithm (why not). Asymptotically there are
only 3 memory access instructions per pixel to do the
deformation. And no integer division, which would be decievingly
slow, even on good hardware. This is the default option, and you
can't turn it off (why would you bother).
-m Try to force use of shared memory. There is a heuristic to decide
automatically if shared memory between the client and the X
server can be used, but it's real bad. So if client and server
run on same machine, but the heuristic fails, try using this
option.
-M Force not to use shared memory. This may be useful if problems
arise with shared memory, or if the program has bugs, and you
don't want to remove shared memory by hand after a segmentation
fault.
-pp The whirling figure is calculated using the formula in polar
coordinates:
R = r
Theta = theta + 2*M_PI*pow(1-sqrt(x*x+y*y),p)
so here you can set p. (p is a double ).
-q Quit on first bounce at lower edge of the screen. The main
interest is for profiling, because there is profiler output only
- 1 - Formatted: April 18, 2024
XWHIRL(1) Rev. 0.1 XWHIRL(1)
3 August 1998
if program trminates normaly.
-r Draw animation on the root window. This seems to accelerate the
animation quite a bit, but may leave permanent garbage on the
display (under circumstances you will soon discover when using
it) until you refresh the whole screen.
-s Use shape extension of the X server. This gives better appearance
by not leaving temporarily garbage in a square shaped area of the
screen when you change parts of the screen behind animation
windows. This option is useful only if -w is used with an
argument > 0.
-u Use saveunder of the X server. This should eliminate blinking at
the edges of the animation window. Useful when -w is used with an
argument > 0.
-wn If n is > 0 then interlace this number of windows to produce the
animation effect. Normally 2 is sufficient. 1 doesn't give a good
effect. If n is < 1 then -r is implied.
PATCHING SOURCES
You may wish to patch the sources to get other amusing effects than
whirling. For this reason you should look at the mkdis() function and
change the dereference table generation. Note that the table is built
to give for each point of the distorted image the source point in the
original image, and not the other way around. That would give a rather
poor quality. (Thanks to Said Ladjal (ladjal@ens.fr) who made me
notice what was originally a bug). The shift algorithme (deplace())
may also be changed to use a circular buffer and the x_offset variable
of the XImage structure, so no data moving will be necessary.
SEE ALSO
ipcs(1), ipcrm(1), XShapeQueryExtension(3X11), XShmQueryVersion(3X11)
BUGS
Shared memory may not be freed after program terminated. So you
should pay attention to verify that shared memory is correctly
released after quitting. In fact shared memory requested from the
system isn't deallocated even after all processes detached it, and
possibly died. Great care is taken in the program to free shared
memory, signals and error conditions are catched. However in some
circumstances (for example if kiled by kill -KILL it can't; or if it
segfaults it refuses to) the shared memory can not be freed. In this
case you should deallocate shared memory explicitly. For this you may
use ipcs(1) and ipcrm(1) Bit and byte order differences between client
and server are not handeled, but in fact algorithms should not be
dependent on it. So this shouldn't cause bugs, but who knows ...
Faster options give worse perfomance, that may be flickering image, or
garbage left on the screen. This is not a bug. That's speed/quality
trade-off. In particular you get very poor performance if you try to
- 2 - Formatted: April 18, 2024
XWHIRL(1) Rev. 0.1 XWHIRL(1)
3 August 1998
collide two deformations (you get nothing reasonable or interesting).
There are only bad heuristics (see the code for your self) to
autodetect wether the client can communicate with the X server via
shared memory. I don't know of a serious way of doing this. First I
used to look at the DisplayString, to see if connection was via a unix
socket. Now I use directly the ConnectionNumber to do statistics on
it, but that's very poor too. I also catch the error message of X if
it fails to attach the shared memory segment, but then there may be
some wierd coincidences, like the same user having the same shmid on
too machines. I could also use magic numbers in addition. Have I
looked over somerthing in the Xlib?? If somebody has an idea, I would
like to hear about it.
AUTHOR
horvai@clipper.ens.fr (Peter Horvai)
Based on an idea seen in a computer store in the form of a screensaver
running on a Windows machine. Code is fully original. The feature is
resemblant to the distort screensaver (xscreensaver/hacks/distort) but
xwhirl is largely optimized, and doesn't do the same kind of
deformation, however it could with minimal addition (somebody would
like to do it?).
- 3 - Formatted: April 18, 2024
