On Sun, Jan 13, 2002 at 06:57:21PM -0700, Eric Christian Carlsen wrote: > My vote is against adopting wmsetbg. I tried to use it with aterm using > transparecy and shading. Every time I moved or resized the window it took > literally two seconds before it fixes the "transparency." It doesn't work well > with aterm if you have transparency and shading. It worked instantly with Eterm > but Eterm gives me lot's of other problems.
Well, the real argument isn't for or against adopting wmsetbg, but rather for how aterm implements transparency, I think. It sounds to me like you're seeing the same effect I am, where aterm takes a significant amount of time to process the changes necessary to the background pixmap. Asking the X server to do it is much faster, it looks like. So, what are YOU using to set this? You should be seeing the same behavior whether you use Esetroot or wmsetbg to control the root pixmap, since wmsetbg also implements the _XROOTPMAP_ID atom (no, shaleh, I haven't suddenly become an X programmer, but 'strings /usr/bin/wmsetbg | grep ROOT' is a wonderful thing ^_^). I've spent the last hour or so playing with Eterm again. I think a lot of prejudices I had against it were due to the Debian package of it. Dunno what's really up with it, but it misbehaves terribly if I install the package from unstable, yet if I build it myself it works fine. It's slower to start up by a measurable interval than aterm is, and gods know it uses more RAM, but once it's up, it seems fine enough. I just wish it supported normal X resources <sigh> -- Marc Wilson [EMAIL PROTECTED] [EMAIL PROTECTED]
