Subject: Really slow iconification

From: Dan Espen <[email-masked]>
Date: Sat, 17 Apr 1999 12:26:19 -0400

On my home Sparc 1+, iconification of a window is taking up to 7 seconds.

For some reason, its slowest on "contool" which supplies its own icon.

I've been trying "gprof" but I think the startup time is drowning out
the iconification time.
>From the man pages, I'm not completely clear on whether profiling can be
turned on and off programatically.

The server seems to be grabbed during the delay.

I see this in 2.3.0, 2.3.1, but not before.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214             E-mail: [email-masked]
Piscataway, NJ 08854                       Phone: (732) 699-5570
--
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: Matthias Clasen <[email-masked]>
Date: Sun, 18 Apr 1999 01:22:25 +0200

I found that the slowdown of iconification only occurs for the
first time a window is iconified, thus CreateIconWindow is the
culprit. Further research showed that the following part of
CreateIconWindow takes the most time:

      XSaveContext(dpy, tmp_win->icon_w, FvwmContext, (caddr_t)tmp_win);
      XDefineCursor(dpy, tmp_win->icon_w, Scr.FvwmCursors[DEFAULT]);
      GrabAllWindowButtons(dpy, tmp_win->icon_w, Scr.AllBindings, C_ICON,
                           GetUnusedModifiers(), Scr.FvwmCursors[DEFAULT],
                           True);
      GrabAllWindowKeys(dpy, tmp_win->icon_w, Scr.AllBindings, C_ICON,
                        GetUnusedModifiers(), True);

So the GrabAll functions may slow down things here.

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: Sun, 18 Apr 1999 03:10:35 +0200

> So the GrabAll functions may slow down things here.

Dan, are you using the IgnoreModifiers command? Although I can't
believe you do it sounds like it. The buttons/windows grabbing
code was rewritten (by me) and moved into the library, but I don't
thint there should be any noticable slowdown unless you have
lots of unused modifiers. Did you perhaps test IgnoreModifiers
and forgot to remove it from your config file? With each ignored
modifier the number of keys/buttons to grab doubles. The XGrab...
can be very slow, especially if you have a slow network connection.

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: Dan Espen <[email-masked]>
Date: Sun, 18 Apr 1999 09:56:13 -0400

> >                         GetUnusedModifiers(), True);

I get the slowdown  every time the window is  iconified, not  just the
first time.

> can be very slow, especially if you have a slow network connection.

Can't remember putting that in my config file...nope.
No "IgnoreModifiers".
I see the slowdown at home, while I'm not connected to any network.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 19 Apr 1999 01:58:46 +0200

> Can't remember putting that in my config file...nope.

I didn't belive it anyway.

> I see the slowdown at home, while I'm not connected to any network.

Could you debug into the GrabAllWindow... functions and see if some
loop is repeated suspiciously frequently?

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Mon, 19 Apr 1999 19:50:43 -0400

> loop is repeated suspiciously frequently?

For each iconification, there is one call to GrabAllWindowKeys
and GrabAllWindowButtons.

The  for  loop  in each   makes about  400 calls  to  GrabWindowKey or
GrabWindowButton.  (I take this to indicate I have about 400 button
and key bindings.  This seems a little high.)

These routines have changed a lot.  The old logic included this:

if ((tmp->Context & C_ICON)&&(tmp->IsMouse == 0))
     ^^^^^^^^^^^^^^^^^^^^^

the new logic seems  to like any context.  (I  admit, I'm lost in this
code.)

I did run a test where I just disabled all of the above code,
and the slowness went away.

Since there is a server grab in each of the GrabAll routines,
I would think it wise to have a GrabAllWindowButtonAndKeys routine,
with only 1 grab for both and only make one pass thru the bindings.

This would halve the grabs and cut 800 function calls to 400.

But  I'm really not  sure  whats going on   in this routine, I assume,
since a key or button is  pushed, its trying to  tell the server, fvwm
has read the key.  Why isn't this done earlier, when  the key event is
associated with an fvwm2 command?

---

From: Dan Espen <[email-masked]>
Date: Tue, 20 Apr 1999 09:44:47 -0400

Dan Espen <[email-masked]> writes:
> > > > >       XSaveContext(dpy, tmp_win->icon_w, FvwmContext, (caddr_t)tmp_wi
> n)
> > ;
> > > > >       GrabAllWindowButtons(dpy, tmp_win->icon_w, Scr.AllBindings, C_I
> CO
> > N,
> > > > >                            GetUnusedModifiers(), Scr.FvwmCursors[DEFA
> UL
> > T],
> > > > >                            True);

I thought 400 was a little high.

A little debugging in "libs/Binding.c AddBinding()" reveals that

Key g R A Beep

results in 2 bindings being added to the list of bindings.

Added binding: keyname g, context 8, mod 8000, action Beep, type 1, bk 88
Added binding: keyname g, context 8, mod 8000, action Beep, type 1, bk 88

(The 2 bindings added seem to be identical.)

All my keybindings appear to be doubled this way

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 21 Apr 1999 02:27:32 +0200

> All my keybindings appear to be doubled this way

Duh, doesn't happen for me. Can you find out how this happens?

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 21 Apr 1999 10:54:54 -0400

> Duh, doesn't happen for me. Can you find out how this happens?

I put this in Bindings.c:

	(*pblist)->NextBinding = temp;
        fprintf(stderr,
          "Added binding: keyname %s, context %X, mod %X,\
 action %s, type %x, bk %d, m %d\n",
                (key_name ? key_name : "?"),
                contexts, modifiers, action, type, i, m);

and I get this:

Added binding:
  keyname e, context 8, mod 0, action WarpTo xemacs, type 1, bk 63, m 0
Added binding:
  keyname e, context 8, mod 0, action WarpTo xemacs, type 1, bk 63, m 2

So whatever "m" is (modifier index?), it adds a  binding for values of
"0" and "2".

For some of my function keys it adds a binding for "0" and "1".

The "simple minded fix" would be to check the binding about to be added
against the binding last added, and if identical, don't add it.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 21 Apr 1999 18:02:59 +0200

> against the binding last added, and if identical, don't add it.

Ah, yes, I thought you referred to calls of AddBinding() itself.
The reason why there are two table entries is that every binding
is duplicated for caps-lock. I didn't see this on my system because
I disabled the caps-lock key in my xmodmap. But that still doesn't
explain why this is slower than before. It was done this way before
the changes. Is AddBinding really called 200 times with different
bindings? Are all of these bindings really in your config file?

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [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: Dan Espen <[email-masked]>
Date: Wed, 21 Apr 1999 12:19:55 -0400

> bindings? Are all of these bindings really in your config file?

Yes, I have about 200 bindings in my config file, resulting in
400 entries in the binding table.  Resulting in about 800 function
calls to iconify a window.

If one is for CAPS LOCK, and one for NOT CAPS LOCK, something is
wrong, since both entries in the binding table appear to be
identical.