Subject: xsrc/20104: Slow xterm updates
To: None <firstname.lastname@example.org>
From: Andreas Gustafsson <email@example.com>
Date: 01/28/2003 23:17:44
>Synopsis: Slow xterm updates
>Arrival-Date: Tue Jan 28 23:18:01 PST 2003
>Originator: Andreas Gustafsson
>Release: NetBSD 1.6L
System: NetBSD guava.araneus.fi 1.6L NetBSD 1.6L (GUAVAMP) #0: Sun Jan 12 16:57:58 PST 2003 firstname.lastname@example.org:/usr/src/sys/arch/i386/compile/GUAVAMP i386
I have two NetBSD-current/i386 systems running X binaries installed
from the NetBSD 1.6 X release sets. On these systems, xterm windows
update very slowly compared with non-NetBSD systems or systems running
older versions of X when areas previously obscured by other windows
Create an xterm window and fill it with text (e.g., by running ls -l).
Create an xbiff window and drag it with the mouse in a circular motion
on top of the xterm window continuously for 10 seconds, using a window
manager configured to display the complete, opaque xbiff window rather
than just an outline while dragging (I use fvwm2, which does this
for windows below a certain size threshold).
Note how the areas under the path of the moving xbiff window turn
white (assuming that is your xterm background color) and stay white
for a remarkably long time, up to several minutes if the movement of
the xbiff window was sufficiently vigorous, while the xterm is slowly
updating one or two characters at a time. By running "top" in a
separate window, you can see how the CPU usage of the X server is
close to 100% during this time.
Tracing the X protocol traffic with xscope shows xterm sending a
large number of ImageText8 requests (which is expected) interspersed
with an even larger number of GrabButton requests (which seems weird
but may or may not be related to the problem).