Subject: FvwmIconMan Patch - Exposing Background Doesnt Redraw

From: Dave Trollope <[email-masked]>
Date: Wed, 22 May 2002 23:28:39 -0500

Hi,

I have for quite sometime been wondering why on my system the
FvwmIconMan background was getting left corrupted when another window
was put on top of it, and then removed. Here is a patch.

The problem was that between 1.4.5 and now, an if() in draw_manager()
was removed and the clear_empty_region() was (I think) moved. However it
was moved to an if() with different conditions - it used to be called
because numWindows > 0 (almost always) but this was no longer true.

So, when an Expose event was received, the draw_managers was called and
the clear_empty_region() was never called. So I added to the dirty_flags
a REDRAW_BG flag, and set it from within man_exposed. This triggers the
redrawing of the background for the expose events.

Please take a look at the patch and include it in the next build.

Thanks
Dave

Index: modules/FvwmIconMan/xmanager.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmIconMan/xmanager.c,v
retrieving revision 1.63
diff -u -u -r1.63 xmanager.c
--- modules/FvwmIconMan/xmanager.c	2002/04/25 11:39:52	1.63
+++ modules/FvwmIconMan/xmanager.c	2002/05/23 04:12:25
@@ -35,6 +35,7 @@
 #define STRING_CHANGED      16
 #define REDRAW_BUTTON       32
 #define GEOMETRY_CHANGED    64
+#define REDRAW_BG           128
 
 /* manager dirty bits: */
 /*      GEOMETRY_CHANGED    64 same as with button */
@@ -1536,9 +1537,12 @@
       set_button_geometry (man, man->buttons.buttons[i]);
   }
 
+  if (force_draw || update_geometry || (man->dirty_flags & REDRAW_BG)) {
+    ConsoleDebug (X11, "\tredrawing background\n");
+    clear_empty_region (man);
+  }
   if (force_draw || update_geometry)
   {
-    clear_empty_region (man);
     /* maybe not usefull but safe */
     if (man->colorsets[DEFAULT] >= 0 &&
 	 Colorset[man->colorsets[DEFAULT]].pixmap == ParentRelative)
@@ -1887,6 +1891,9 @@
   h2 = man->geometry.boxheight;
 
   bp = man->buttons.buttons;
+
+  /* Background must be redrawn */
+  man->dirty_flags |= REDRAW_BG;
 
   if (FHaveShapeExtension)
   {
Index: ChangeLog
===================================================================
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.1803
diff -u -u -r1.1803 ChangeLog
--- ChangeLog	2002/05/22 19:37:38	1.1803
+++ ChangeLog	2002/05/23 04:20:15
@@ -1,3 +1,10 @@
+2002-05-22  Dave Trollope  <[email-masked]>
+
+	* Modules/FvwmIconMan/xmanager.c:
+	(draw_manager): 
+	(man_exposed):
+	Fix for background not being redrawn when the window is exposed.
+
 2002-05-22  olicha  <[email-masked]>
 
 	* libs/Flocale.h:

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 27 May 2002 12:18:43 +0200

> Please take a look at the patch and include it in the next build.

Hm, wasn't that already fixed?  For which release is that patch?
2.4.x or 2.5.x?

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20

--
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: Dave Trollope <[email-masked]>
Date: Tue, 28 May 2002 20:11:37 -0500

Hi Dominik,

I was setup for the latest code in cvs, 2.5.2 is what fvwm -v shows.

I've seen this behaviour ever since 2.4.5, never seen it fixed since I've been
on the ML.

I'm thinking perhaps I should regenerate the patch, I realised just now I put
the #define in the wrong set of defines. It doesn't cause a problem but the
correct place is a few lines down. I will re-issue the patch - especially
since I see others have added patches in the last few days too.

Cheers
Dave

---

From: Dave Trollope <[email-masked]>
Date: Tue, 28 May 2002 20:11:53 -0500

Hi Dominik,

Cheers
Dave

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 29 May 2002 01:27:59 +0000

> since I see others have added patches in the last few days too.

Dominik already applied your patch, probably on accident.

Regards,
Mikhael.

---

From: Dave Trollope <[email-masked]>
Date: Tue, 28 May 2002 21:28:10 -0500

Hi Dominik,

Here is a new patch to move the REDRAW_BG #define to the manager dirty bits
instead of the button dirty bits. I grouped it with the wrong defines. This is
for 2.5

Cheers
Dave

Index: ChangeLog
===================================================================
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.1813
diff -u -u -r1.1813 ChangeLog
--- ChangeLog	2002/05/27 21:27:14	1.1813
+++ ChangeLog	2002/05/29 01:56:01
@@ -1,3 +1,9 @@
+2002-05-27  Dave Trollope  <[email-masked]>
+
+	* Modules/FvwmIconMan/xmanager.c:
+	Changed the REDRAW_BG from 128 to 16 and moved to manager dirty bits
+ 	group.
+
 2002-05-27  olicha  <[email-masked]>
 
 	* acinclude.m4:
Index: modules/FvwmIconMan/xmanager.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmIconMan/xmanager.c,v
retrieving revision 1.65
diff -u -u -r1.65 xmanager.c
--- modules/FvwmIconMan/xmanager.c	2002/05/27 12:02:49	1.65
+++ modules/FvwmIconMan/xmanager.c	2002/05/29 01:46:55
@@ -35,13 +35,13 @@
 #define STRING_CHANGED      16
 #define REDRAW_BUTTON       32
 #define GEOMETRY_CHANGED    64
-#define REDRAW_BG           128
 
 /* manager dirty bits: */
 /*      GEOMETRY_CHANGED    64 same as with button */
 #define MAPPING_CHANGED     2
 #define SHAPE_CHANGED       4
 #define REDRAW_MANAGER      8
+#define REDRAW_BG           16
 
 /* ButtonArray dirty bits: */
 #define NUM_BUTTONS_CHANGED 1

---

From: Dave Trollope <[email-masked]>
Date: Tue, 28 May 2002 23:35:13 -0500

Hi,

Mikhael Goikhman wrote:

> [LARGE QUOTE SNIPPED]

> Dominik already applied your patch, probably on accident.

When I went to recreate it I noticed that and simply generated a new diff with the
#define moved so it can be applied on top.

Thanks!
Dave

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 29 May 2002 14:05:40 +0200

> Dominik already applied your patch, probably on accident.

Nope, that was on purpose :-)

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 29 May 2002 14:09:02 +0200

> instead of the button dirty bits. I grouped it with the wrong defines. This is

Thanks, I'll apply it.  Could you please make the same patch for
2.4.7?

> Index: ChangeLog

BTW, that's the wrong ChangeLog file.  Changes in the modules
directory are logged in fvwm/modules/ChangeLog.

Bye

Dominik ^_^  ^_^

---

From: Dave Trollope <[email-masked]>
Date: Wed, 29 May 2002 19:48:20 -0500

Hi Dominik,

> Thanks, I'll apply it.  Could you please make the same patch for

Funny you say that, I downloaded the 2.4 branch to do just that, but I found the
clear_empty_region() is still called based on num_windows:

void draw_manager (WinManager *man)
{
  int i, force_draw = 0, update_geometry = 0, redraw_all = 0;
  int shape_changed = 0;
[snip]
  if (redraw_all || (man->buttons.dirty_flags & NUM_WINDOWS_CHANGED)) {
    ConsoleDebug (X11, "\tresizing manager\n");
    resize_manager (man, redraw_all);
    update_geometry = 1;
    force_draw = 1;
  }
  if (force_draw || man->buttons.num_windows != 0)
    clear_empty_region (man);
...

This is in pretty much all cases. It was this last if that was removed in 2.5.x so I
don't think this fix is necessary in 2.4.x

> directory are logged in fvwm/modules/ChangeLog.

Sorry, will do it there next time.
Thanks!
Dave

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 31 May 2002 11:14:13 +0200

> clear_empty_region() is still called based on num_windows:

I didn't check 2.4.7 since you said the problem began in 2.4.5 (?)

Bye

Dominik ^_^  ^_^

---

From: Dave Trollope <[email-masked]>
Date: Fri, 31 May 2002 21:03:41 -0500

Hi Dominik,

My original email said "between 1.4.5 and now an if was changed in..." which did as you
assumed correctly mean 2.4.5 and now. I mean it worked ok in 2.4.5 but didn't work now.
I first noticed the problem in snap-20020317 (2.5.1). Finally got to looking at what
caused it (at the time I was looking at the malloc calls). Was surprised it was ok in
2.4.X still.

I intend to start looking at the processing of the NotifyMotion events because I think
we can find some inprovement in handling that event since it is received by apps
registered for it much more than any event. I noticed that it is in the main switch for
FvwmIconMan. I'm trying to measure right now the gain by having an if trap this event
prior to entering the switch(). switch() is slower when 1 case is called significantly
more times than any other case. What do you think?

Cheers
Dave