Subject: Re: fvwm doing xsync reading almost every command

From: Dominik Vogt <[email-masked]>
Date: Mon, 4 Sep 2000 18:39:57 +0200

On Sat, Aug 26, 2000 at 08:41:10PM +0300, Mikhael Goikhman wrote:
> > I find that commands that shouldn't take any time at all,
> > like "AddToFunction", take an average of 1/4 elapsed seconds.
> 
> A really bad bug.

Yes.

> > I traced that 1/4 second down to functions.c ExecuteFunction() around
> > line 1035 where it has this:
> > 
> >   /* Only wait for an all-buttons-up condition after calls from
> >    * regular built-ins, not from complex-functions, menus or modules. */
> >   if(Module == -1)
> >     WaitForButtonsUp(True);
> > 
> > The condition "Module == -1" is true for just about every command.
> > Only blank lines and comments get away with zero measurable elapsed time.
> > 
> > For startup, the Module switch seems to originate in fvwm.c around line
> > 639:
> > 
> > All  those  "run_command_file"   and "ExecuteFunction"  commands   are
> > passing "-1" for the "Module" value causing all the XSync calls.  This
> > appears  to be the way fvwm  has worked since  at  least 2.2.  (2.2 is
> > also slow run this way.)
> > 
> > I changed all the above "-1" to another value with no obvious negative
> > consequences.  I don't know for sure what that does to startup time,
> > the first test seemed to show improvement.
> > 
> > I don't think thats the right fix for this.
> > It would seem to me, the decision about which commands need to be
> > XSync'd should be made based on the command, or possibly the command
> > and its arguments.
> > 
> > Any comments?

I'm not sure if this "Module" parameter is useful anyway.  I *believe*
it's meant to indicate: "Hey, we are running a script, so do not wait
for any user interaction".  If so, we have to redesign this parameter:
(a) give it a proper name and (b) check every place where it is used.
Furthermore the Read/Piperead commands should set this "scripting" flag
too.

> I think, your fix (disallow WaitForButtonsUp for startup commands) is ok.
> We grab a busy cursor during start-up commands anyway. Maybe to call
> WaitForButtonsUp after that block.
> 
> Your suggestion of calling WaitForButtonsUp based on the command name
> (I don't think parsing arguments is needed/possible) also can be used
> to speed up the run time commands.

> Probably Dominik, who worked with
> this function, can comment better on this suggestion after his vacation.

:-)

I'll take a look at this when I'm through the mail (still 100+
unread mails left).

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-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]