Well, if I can get the CPU to peg without even starting XMMS, why
would
that matter? But just for the sake of completeness, I've got a Crystal
SoundFusion CS 4614 sound card, using the cs46xx driver (whith
"thinkpad=1" passed as an option in /etc/modules.conf).
Incidentally, if I boot into runlevel 3 and then ssh in and run 'ls -lR /'
remotely, the CPU is fine. If I start X (KDE, in my case) and run that
same command from a konsole window, the CPU usage spikes to 100% (looks
like X is about 60% and kdeinit is 30%, with the rest being ls). If I run
GNOME and ran that same command locally, gnome-terminal likes to grab
about 85% of the cpu. Running ls remotely while GNOME is up uses no
appreciable CPU.
XMMS skips when I run that command locally, playing either OGG or MP3
files. It does not skip when I run it remotely. I don't think the
problem is with XMMS. Any other app (gkrellm, mozilla,
gnome-system-monitor, etc) all "skip" (eg, fail to redraw screen bits)
when the CPU usage approaches 100%.
I'll go file a bug report with bugzilla.
It is likely anti-aliased fonts doing it. Trying to hint every character
for the tons of text scrolling is cpu intensive. I have mentioned it to
mharris before and he said something like the anti-alias font code isn't
accelerated. One idea I had to workaround the problem was to put a
scroll rate limiter into terminal window software like gnome-terminal.
Though it could be annoying to watch it scroll at a slower pace. Another
potential workaround would be to realize when you are scrolling faster
than can be read and disabling anti-aliasing.