Subject: xsrc/20104: Slow xterm updates
To: None <gnats-bugs@gnats.netbsd.org>
From: Andreas Gustafsson <gson@gson.org>
List: netbsd-bugs
Date: 01/28/2003 23:17:44
>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: