On 17:33 14 Jan 2003, RvB <rvb_at_rvb.dyndns.org> 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.
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.
--
Cameron Simpson, DoD#743 cs_at_zip.com.au http://www.zip.com.au/~cs/
Truly, the ultimate demonstration of the computer's utility is that it
continues to be indispensable in spite of those who run the things.
- Steve Glass
--
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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue Jan 14 2003 - 18:31:00 GMT