This might be specific to evilwm or similar. I work with several xterm windows open, and when one partially covers another, the partially covered window seems to make some bad assumptions about which area is covered and fail to redraw properly until covered and uncovered again, particularly when scrolling up and down in vim on the bottom window (evilwm allows you to work in windows without bringing them to the front). Reproducible: Sometimes Steps to Reproduce: 1.Open 2 or more xterm windows with one partially covered 2.Open vim in the bottom window and scroll up and down w/ page up/down keys 3.Garbage from one line mixes with another line Portage 2.1.3.9 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22-gentoo-r5 i686) ================================================================= System uname: 2.6.22-gentoo-r5 i686 AMD Opteron(tm) Processor 142 Timestamp of tree: Sat, 20 Oct 2007 11:50:01 +0000 app-shells/bash: 3.2_p17 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r5, 2.5.1-r2 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.mirrors.easynews.com/linux/gentoo/ http://gentoo.chem.wisc.edu/gentoo/ http://mirror.phy.olemiss.edu/mirror/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LINGUAS="en ja" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="3dnow X aalib alsa ao apache2 avi bash-completion berkdb bitmap-fonts cairo cdr cjk cli cracklib crypt cups dbus divx4linux dri dvd dvdr eds emboss encode fam fbcon firefox flac fortran gcj gd gdbm gif glut gpm gstreamer gtk gtk2 hal iconv ipv6 isdnlog jack javascript jpeg ldap libcaca mad midi mikmod mmx mp3 mpeg mplayer mudflap mysql ncurses nls nptl nptlonly ogg opengl openmp pam pcre pda pdf perl png posix ppds pppd python qt4 quicktime readline reflection samba sdl session spell spl sse ssl svg svga tcpd tetex theora truetype truetype-fonts type1-fonts unicode vorbis win32codecs wmf x86 xml xorg xv xvid zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="mouse keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en ja" USERLAND="GNU" VIDEO_CARDS="fglrx radeon vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 134047 [details] Problem caught on camera You can see in this image parts of pink text from another line are visible behind the text.
for a quick check, I'm not seeing this (using vim in uxterm, under fvwm which also allows working in partly-obscured windows). It may depend on the file contents - or on the window manager (though that's less important usually than the flavor of the X server). I'm running Debian/testing.
(In reply to comment #2) > It may depend on the file contents - or on the window manager > (though that's less important usually than the flavor of the > X server). Then I suppose I should have mentioned I'm using xorg-server-1.3.0.0-r1 (with ati-drivers-8.39.4, but I don't think that should matter). Thanks for looking into it so fast.
(no problem - I have to collect information to see if I can fix it). I'm not sure which details would matter. At the moment, another detail occurs to me - I tested with the bitmap fonts. Trying a truetype font now does not seem to make any difference. My xorg is comparable version, but different driver: SAVAGE: driver (version 2.1.3) for S3 Savage chipsets. I believe the window manager is the least suspect here; if it is xterm, you "should" be able to reproduce the problem with a different X server (noting that running remotely versus running locally exercises different logic in the X server...).
I get exactly the same results under fvwm. I also figured out how to reliably reproduce the problem. 'make menuconfig' in the kernel directory (in the place of vim as suggested earlier) seems to always have the issue when the window it's in is partially covered. I forgot to mention (but it should be obvious from the screenshot) that the problem only happens side-to-side near the top and bottom of the covering window, never top-to-bottom.
Created attachment 155301 [details] Another screenshot
Please retry with up-to-date X, drivers and xterm.. Just pinging to see if there's any life here :-)
There is, by the way, a different repainting bug reported for #242, which is fixed in my patches toward #244. (It's mixed in with a larger change that's still in-progress).
I haven't used the system this happened on in a while. I'll see if I can bring it up and check sometime soon, but it won't be right away.
(In reply to comment #8) > There is, by the way, a different repainting bug > reported for #242, which is fixed in my patches > toward #244. (It's mixed in with a larger change > that's still in-progress). > Yep, I've seen #243a/b/c/d patches. But there seems to be releases too in steady pace :)
yes - but sometimes I find that I have to stop in the middle of large changes to make smaller fixes available as a release. (If the newer bug isn't a show-stopper, I'll continue on the large change...).
*xterm-248 (24 Sep 2009) 24 Sep 2009; Samuli Suominen <ssuominen@gentoo.org> +xterm-248.ebuild: Version bump. Please test.
