On Wed, Jan 15, 2003 at 11:29:29AM +1100, Cameron Simpson wrote: > On 17:33 14 Jan 2003, RvB <[EMAIL PROTECTED]> wrote: > | On Tue, Jan 14, 2003 at 08:15:17AM +0100, Dominik Vogt wrote: > | > I guess you have to ask the Eterm developers about this. > | > | i think it is not actually an eterm problem, it also happens with rxvt > | and many similar programmes. it also happens to transparent window > | titlebars of fvwm. they are refreshed the whole time while moving, which > | takes a lot of cpu time. it would be a lot better if there was an option > | for the window to be refreshed after the move or resize is actually finished. > | :) > | in other windowmanagers, (enlightenment, afterstep, wmaker, ...) > | "transparency" acts like this, and it is a lot resource-friendlier ... > | and as i said it is not an Eterm-specific problem :) > > I would guess one of two things is happening then (under E): > > - you're doing a wire-frame (outline) move, so no > window redraws happen > I don't think this is what you are describing.
> - E is doing a window grab, letting you slide around > a view of the grab, _then_ moving the real window > when you let go of the mouse (probably withdrawing the window > during the move so you see only the grab > > With FVWM's opaque move the window sees all the intermediate positions and > does nots of redrawing if it's transparent. Yes, that is almost certainly what is happening. The ICCCM2 requires that the WM informs the window of all intermediate positions. > One test (under E) would be to move a busy window. > Eg put up a plain xterm with > > while sleep 1; do date; done > > Running in it, see it scroll. Now grab the window and move it around. > Does the scrolling cease during the move? The I suspect my second hypothesis > above. Bye Dominik ^_^ ^_^ -- Visit the official FVWM web page at <URL: http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
