Subject: FVWM: moving the Eterm

From: Klaus Umbach <[email-masked]>
Date: Sun, 12 Jan 2003 16:48:33 +0100

Hello list,

When I move my transparent Eterm, it updates its background all the
time, when I used Enlightenment it updated the background when the
window was released. That makes a lot less CPU-load.
Because I have "PlaceAgain Anim" in my focus-and-raise function that may
become really slow, when a window ist big.

Can I somehow switch to the Enlightenment-style?

Klaus
-- 
5) People say Linux is ugly. How does that make you feel?
Torvalds: They'll be the first against the wall when the revolution comes.
	  Let's see just how ugly they think it is when they have a few
	  bulletholes in them.

--
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-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 14 Jan 2003 08:15:17 +0100

> Can I somehow switch to the Enlightenment-style?

I guess you have to ask the Eterm developers about this.

Bye

Dominik ^_^  ^_^

---

From: RvB <[email-masked]>
Date: Tue, 14 Jan 2003 17:33:26 +0100

On Tue, Jan 14, 2003 at 08:15:17AM +0100, Dominik Vogt wrote:

hi :)

> 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 :)

bye
	RvB <[email-masked]>
		http://rvb.dyndns.org

---

From: Cameron Simpson <[email-masked]>
Date: Wed, 15 Jan 2003 11:29:29 +1100

On 17:33 14 Jan 2003, RvB <[email-masked]> 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        [email-masked]    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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 14 Jan 2003 17:45:37 +0100

> for the window to be refreshed after the move or resize is actually finished.

Really, fvwm is just honouring standards.  Any decent
implementation of transparency (in an application) suppresses most
of these redraws.

> and as i said it is not an Eterm-specific problem :)

Right, then it's a problem in E, afterstep, wmaker, ... too.  The
standard (ICCCM2) is very clear about the right behaviour.  If
other WMs are ignoring this standard, it's their problem, not
fvwm's.

But to be honest I suspect that you are running very old versions
of Eterm, rxvt and said window managers.  As far as I know, the
latest versions of the terminal programs have already been fixed.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 15 Jan 2003 08:09:45 +0100

> 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.

Bye

Dominik ^_^  ^_^

---

From: Klaus Umbach <[email-masked]>
Date: Wed, 15 Jan 2003 10:33:40 +0100

> latest versions of the terminal programs have already been fixed.

I have the latest stable version of Eterm: 0.92
Wouldn't it be nice to have an Option to change this behaviour? 
By the Way: what other windowmanager use the ICCCM2-standard?

Klaus

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 15 Jan 2003 09:56:42 +0000

> By the Way: what other windowmanager use the ICCCM2-standard?

Just tried sawfish-1.0 + "fvwm-root -r bg_image" + Eterm-0.9.1.
It behaves exactly like with fvwm, i.e. Eterm blinks all the way.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 15 Jan 2003 11:15:00 +0100

> By the Way: what other windowmanager use the ICCCM2-standard?

Most modern window managers do.

Bye

Dominik ^_^  ^_^

---

From: Mark Krenz <[email-masked]>
Date: Wed, 15 Jan 2003 08:32:51 -0500

> does nots of redrawing if it's transparent.

  I think that it would be better if fvwm just kept the current state of
the window in memory without trying to update it until you released the
window.  After all, you do an opaque move just so you can see what the
whole window will look like in it's new place, not so that you can move
the window around while watching it update.  Can a new option be added
to OpaqueMoveSize called 'nice', or something like that?

-- 
 mark.krenz
 [email-masked]
_______________________________________________________________________________
Patent #1367490421
It's a samurai sword that shouts 'WARNING!' at the first sign of danger and
improves upper-body muscle.
--
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-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 15 Jan 2003 15:10:25 +0100

> to OpaqueMoveSize called 'nice', or something like that?

Yeah, just turn opaque move off if you don't like it.  That's what
wire frame move is for ;-)

Seriously, there is no reliable ways to find out the window
contents to make a copy of the window that is moved around.

Bye

Dominik ^_^  ^_^

---

From: Mark Krenz <[email-masked]>
Date: Wed, 15 Jan 2003 09:26:49 -0500

> contents to make a copy of the window that is moved around.

  Um, I don't buy that for a second since I see it done all the time by
programs that keep track of their own state, background image position,
transparency, etc.  How hard can it be for fvwm to just grab the screen
in the position the window is in and move it around.  I would put up
with the 1 second it would take to grab the screen if it meant that I
could move the windows around without hogging the CPU.

Patent #756298483
It's a fizzy drink! It encrypts all of its data!

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 15 Jan 2003 15:34:44 +0100

On Wed, Jan 15, 2003 at 09:26:49AM -0500, Mark Krenz wrote:
> in the position the window is in and move it around.

To answer your question:  it's impossible to do reliably.  Nothing
on earth (except patching the X server) can make it keep the
contents of windows in memory that are buried below other windows
or partially of screen.  That works only for the limited case that
the window is *fully* visible at the time you start moving.  I
think E has something like this, but they drag a partially
transparent pane in the size of the window around the screen.

> I would put up

Bye

Dominik ^_^  ^_^

---

From: RvB <[email-masked]>
Date: Sat, 18 Jan 2003 17:39:11 +0100

> latest versions of the terminal programs have already been fixed.

i just tried the latest unstable rxvt version and the terminal of gnome2
... they refresh after the move is finished, and never during the move
:) ... so it's right, it is not fvwm's fault :>

but it's quite strange if none of E, afterstep, wmaker ... don't support
ICCCM2 yet ... it's cool that fvwm 2.5 already supports it :)

bye
	RvB <[email-masked]>

---

From: RvB <[email-masked]>
Date: Sat, 18 Jan 2003 17:40:06 +0100

bye
	RvB <[email-masked]>