Subject: CVS domivogt: * Removed flash when maximizing rxvt windows.

From: FVWM CVS <[email-masked]>
Date: Tue, 19 Mar 2002 10:17:36 -0600

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	02/03/19 10:17:36

Modified files:
	.              : ChangeLog 
	fvwm           : frame.c 

Log message:
* Removed flash when maximizing rxvt windows.

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Tue, 19 Mar 2002 11:30:53 -0500

> * Removed flash when maximizing rxvt windows.

I still see it.
I use the keyboard to maximize.
My rxvt windows have a background pixmap.

-- 
Dan Espen                           E-mail: [email-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Mar 2002 22:02:46 +0100

> My rxvt windows have a background pixmap.

On the way to my dancing training I came up with the idea why it
flashes and a way to get rid of it once and for all.  THe problem:
With window gravities, you can tell X to automatically move child
windows, but you can not tell it to resize them.  Since the client
window is a sub sub window of the frame, you can not resize or
move it to its final position in the same operation as the parent
and the frame.

At the moment, when a window is maximized, the client is resized
first (this generates a ConfigureNotify which may cause the client
to redraw).  Then the parent is resized, then the frame.  Since
fvwm and the client send their commands asynchronously to the
server, the parent's or frame's background may become visible for
a split second before the client gets Expose events and covers it.

Because of the three tiers in the window hierarchy, it's
impossible to prevent this effect completely.  What happens is
that some areas of the frame may get redrawn multiple times.  This
is not only visually disturbing but also slow.

Here is the good news: it *is* possible to suppress all the
superflous redraws.  Set the background pixmap of the parent and
the frame to 'None', resize them before resizing the client and
then resize the client.  Because of the undefined background, the
X server simply keeps the contents of the now exposed areas.
Let's try...

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 20 Mar 2002 23:01:23 +0100

On Tue, Mar 19, 2002 at 10:02:46PM +0100, Dominik Vogt wrote:
> flashes and a way to get rid of it once and for all.

[snip]

Unfortunately, nothing of this is reliable.  The is no way to
prevent the flash in all cases.  I believe, what you see is the
background of the rxvt window right before it can resize its
text window and the scrollbar.  I can't think of any way to
prevent this in fvwm.  rxvt should set the bg pixmap to its top
level window, but that isn't a solution.  Since X doesn't support
"recursive resizing", it can't be done.

At least:  I compared the current fvwm code with what about ten
other WMs do (E, Afterstep, Blackbox, MWM, olvwm, kwin, ...) and
none of them comes close to fvwm.  They all flash and flicker like
hell.

Bye

Dominik ^_^  ^_^