Bug#432847: /usr/bin/xload: xload needs a way to limit range of values it can display
Package: x11-apps
Version: 0.1
Severity: wishlist
File: /usr/bin/xload
The vertical scale of xload adjusts to accommodate the highest load level.
It has horizontal lines to indicate the vertical scale.
A high enough load shall cause these lines to be so closely spaced
that there is no space between them: the entire display is then white
(I have reverse video set, so the background is black and scale lines
are white) and I can no longer see the load varying, on account of the
lines. Modern machines can endure quite immense loads, so this
problem can readilly arise (I routinely get it when running make -j -l
12, if some of the processes make first fires off do very vigorous
things once started). The machine is happy, but xload becomes useless !
If the load has a transient spike, the vertical scale adapts to let
the spike's top be displayed: if the spike is high enough, xload
becomes useless until the spike has scrolled off the left hand end -
or until I kill it and start a fresh xload, losing all the data that
was on display for the prior four hours (yes, xload is almost the full
width of my screen).
Note that setting the foreground colour of xload doesn't help: the
grid lines are drawn on top of the load data, so would hide it.
This could readilly enough be remedied by providing a command-line
option, --clip-at=n, to tell xload to not try to display any load
level above n. More fancy solutions are possible.
It may be sufficient simply to draw the load data on top of the scale
lines; then -foreground=red would suffice to make the load graph's
shape visible, even when the scale lines are so closely packed as to
form a featureless background (giving no indication of scale - other
than "OMG that's high !").
If the vertical scale is huge enough that the horizontal lines use up
more than (say) half of the pixels available for vertical height (at
this point, it's possible - but getting hard - to read the display),
xload could drop the granularity of its vertical scale; only display
one in 10 of the horizontal lines, for example. Naturally, this would
require some way to indicate that the scale has been adjusted;
e.g. the load-level difference between horizontal lines could be
displayed in the top left corner of the chart. Of course, the value
of 10 (the base of the number system in use) could be controlled by a
command-line parameter; or it could just be hard-coded to ten or 0x10.
Alternatively, the horizontal lines could be dashed, with multiples of
10 using longer dashes (and multiples of 100 using longer ones yet).
The dashes for adjacent values should be staggered, so that they don't
simply from a solid vertical column (hiding data in the interval it
spans).
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages x11-apps depends on:
ii cpp 4:4.1.1-15 The GNU C preprocessor (cpp)
ii libc6 2.5-9+b1 GNU C Library: Shared libraries
ii libfontconfig1 2.4.2-1.2 generic font configuration library
ii libice6 1:1.0.3-2 X11 Inter-Client Exchange library
ii libpng12-0 1.2.15~beta5-2 PNG library - runtime
ii libsm6 2:1.0.3-1 X11 Session Management library
ii libx11-6 2:1.0.3-7 X11 client-side library
ii libxaw7 1:1.0.3-3 X11 Athena Widget library
ii libxcursor1 1:1.1.8-2 X cursor management library
ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar
ii libxft2 2.1.12-2 FreeType-based font drawing librar
ii libxkbfile1 1:1.0.4-1 X11 keyboard file manipulation lib
ii libxmu6 1:1.0.3-1 X11 miscellaneous utility library
ii libxmuu1 1:1.0.3-1 X11 miscellaneous micro-utility li
ii libxrender1 1:0.9.2-1 X Rendering Extension client libra
ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library
ii x11-common 1:7.2-5 X Window System (X.Org) infrastruc
x11-apps recommends no packages.
-- no debconf information
Reply to: