Subject: FVWM: Patch to eliminate blink

From: Dan Niles <[email-masked]>
Date: Fri, 3 May 1996 11:05:45 -0500

Here is a patch that eliminates the blink of border color when a window
is closed.

This is not the most elegant solution, but it shows that the problem is
the order in which the window is closed.

------------------------- fvwm-2.0.42-NoBlink.patch --------------------------
--- builtins.c.orig	Wed Apr 10 12:38:25 1996
+++ builtins.c	Fri May  3 11:02:22 1996
@@ -598,6 +598,7 @@
   
   if (tmp_win->flags & DoesWmDeleteWindow)
   {
+    XUnmapWindow(dpy, tmp_win->frame);
     send_clientmessage (tmp_win->w, _XA_WM_DELETE_WINDOW, CurrentTime);
     return;
   }
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Dan Espen <[email-masked]>
Date: Fri, 03 May 1996 12:32:42 -0400

----------
> +++ builtins.c	Fri May  3 11:02:22 1996

Ahh, finally some progress.

I'm not  sure we are  on  the same  track,  I never noticed  any frame
blinking.   What I see is the  frame filling with the "unhilite color"
during window takedown.

I tried this:

Around line 1900 in builtins.c, I removed this line:

 XUnmapWindow(dpy,w);

Therefore  only unmapping the frame.   I think it automatically unmaps
the window inside.  This seems to fix the frame filling problem during
iconify, but I still  see the frame  fill when I exit  an application.
(For example typing "q" in an xv window.)

Any testing has to be done with the cpu very busy.

It does seem to speed up iconifying also.

--
Dan Espen                                    Phone: (908) 699-5570
[email-masked]
444 Hoes Lane  Room RRC 1C-214
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Dan Espen <[email-masked]>
Date: Fri, 03 May 1996 12:48:41 -0400

----------
> Here is a patch that eliminates the blink of border color when a window

Sorry, I am going a little too fast.  What I also did is remove
these lines from icons.c:

around line 787.

	  XSelectInput(dpy, t->w, eventMask & ~StructureNotifyMask);
          XUnmapWindow(dpy, t->w);

(Still just unmapping the frame.)

---

From: Dan Niles <[email-masked]>
Date: Fri, 3 May 1996 11:56:05 -0500

[clip]

> blinking.   What I see is the  frame filling with the "unhilite color"

Yup, same track.  On my computer it appears as a blink of the unhilight color.

> (For example typing "q" in an xv window.)

I believe that the problem is with the application closing itself down and
unmapping itself.  The proper fix would be to redo the unmapping so that
whenever a window is unmapped, it unmaps the frame first.  I am not entirly
certain how to do this when the application kills itself (q in xv).
It might be possible to do this by modifying the windows event mask. 

> Any testing has to be done with the cpu very busy.

That is very difficult for me to do, I have a very fact computer. :)

Dan Niles
[email-masked]

---

From: [email-masked]
Date: Fri, 3 May 96 18:12:58 +0100

> +++ builtins.c Fri May  3 11:02:22 1996

Ah yes, you can do that, and it's reasonably elegant, but it doesn't solve the
problem entirely.
In fact, I was looking at the problem from the other point of view where the
application destroys its own window, leaving the frame window behind.  How does
the window manager trap that before it happens.  I now believe it cannot.  I
think it can only wait until it gets the UnmapNotify or the DestroyNotify
through the SubstructureRedirectMask.

  Cheers,
    Jonathan.

---

From: [email-masked]
Date: Fri, 3 May 96 18:25:23 +0100

> > ------------------------- fvwm-2.0.42-NoBlink.patch
-------------------------
> > -
> the window inside.

Yes, but then, when the app queries its display state, it will get Mapped (I
think), rather than Unmapped.  I think we need to unmap the frame first, and
then unmap the application window.  Of course, the second unmap doesn't have any
visual effect, it just keeps the application sweet.

>  This seems to fix the frame filling problem during

Yup, that's the one I was aiming for.

Jonathan.

---

From: Todd Tyrone Fries <[email-masked]>
Date: Fri, 3 May 1996 19:35:04 -0600 (MDT)

> That is very difficult for me to do, I have a very fact computer. :)

If you're really serious about observing the events in proper order, try running
fvwm in synchronous mode, try using strace -p<pid>, and try MEM=4M or something
like that on the command line of the kernel, or try any combination of the above.

-- 
Todd Fries