>Number: 20104
>Category: xsrc
>Synopsis: Slow xterm updates
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: xsrc-manager
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jan 28 23:18:01 PST 2003
>Closed-Date:
>Last-Modified:
>Originator: Andreas Gustafsson
>Release: NetBSD 1.6L
>Organization:
>Environment:
System: NetBSD guava.araneus.fi 1.6L NetBSD 1.6L (GUAVAMP) #0: Sun Jan 12 16:57:58 PST 2003 gson@guava.araneus.fi:/usr/src/sys/arch/i386/compile/GUAVAMP i386
Architecture: i386
Machine: i386
>Description:
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
are exposed.
>How-To-Repeat:
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).
>Fix:
Unknown.
>Release-Note:
>Audit-Trail:
>Unformatted: