Subject: FVWM: 2.5.9 redrawing still slow

From: Elliot Sowadsky <[email-masked]>
Date: Tue, 2 Mar 2004 11:55:20 -0800 (PST)

2.5.8 had a problem for me of being slow.
2.5.9 shows the same problem.
2.5.7 is ok.
The menu background opens quick but then takes about a second to fill in.
Even w/ no .fvwm2rc, the default root menu takes a little while to fill in.
Switching desks is also slower than on 2.5.7

I'm running solaris 5.8 on an ultra 10, starting from xinit.

My config is...

env CXX=g++ CC=.../bin/gcc LDFLAGS=-s CFLAGS="-O3" ./configure --without-cxx  \
--with-xpm-includes=.../X11/include --with-xpm-library=.../X11/lib
--disable-shape --disable-sm --disable-bidi --with-iconv-library=no --without-gnome

(... = path)
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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: Duane Paddock - Personal <[email-masked]>
Date: Wed, 3 Mar 2004 08:21:19 -0500 (EST)

I am also experiencing the same slowness using the default system.fvwm2rc
configuration file on an Ultra 60 with Solaris 8 and the latest patches 
from patchpro.

I've tried both gcc 3.2.3 and Sun's forte 7 C compiler with the same 
result; 2.5.7 is fast; both 2.5.8 and 2.5.9 are dog slow by comparison.

$ fvwm-config -v
2.5.9

$ fvwm-config -s
gettext
gtk
gdk-imlib
iconv
perllib
png
readline
rplay
shape
shm
sm
xpm

The make still fails on the debian directory was well. I have to remove
the debian directory from the SUBDIRS variable of the top level Makefile
for the compile to complete successfully;

-- snip --
Making all in debian
make: Fatal error in reader: Makefile, line 333: Badly formed macro assignment
Current working directory 
/home/dp130708/source/fvwm-2.5.9/fvwm-2.5.9/debian
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /home/dp130708/source/fvwm-2.5.9/fvwm-2.5.9
*** Error code 1
make: Fatal error: Command failed for target `all'
Current working directory /home/dp130708/source/fvwm-2.5.9/fvwm-2.5.9
*** Error code 1
make: Fatal error: Command failed for target `all'

$ cat -n Makefile | ggrep -B 5 -A 5 333     
   328            fi; \
   329            (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
   330             || case "$$amf" in *=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac; \
   331          done && test -z "$$fail"
   332  tags-recursive:
   333          list='$(SUBDIRS)'; for subdir in $$list; do \
   334            test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
   335          done
   336
   337  ETAGS = etags
   338  ETAGSFLAGS =

$ gmake --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for sparc-sun-solaris2.7
-- snip --

This problem first appeared in the 2.5.8 release tarball.

http://www.mail-archive.com/[email-masked]/msg04783.html

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 3 Mar 2004 14:26:45 +0000

> make: Fatal error in reader: Makefile, line 333: Badly formed macro assignment
  ^^^^^
          This would be "gmake", I guess.

> $ cat -n Makefile | ggrep -B 5 -A 5 333     

It says about debian/Makefile, not Makefile.

I will replace the strange syntax in that line (is it GNU make-ism?).

> Built for sparc-sun-solaris2.7

Your GNU make version is fine, but it is not clear whether your make and
gmake are the same thing. Please report your make version output.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 3 Mar 2004 15:48:26 +0000

On 03 Mar 2004 10:30:15 -0500, Duane Paddock - Personal wrote:
> 
> Mikhael,
> 
> Is there some way we can track down the slow drawing issue?  I'd really 
> like to be able to upgrade from 2.5.7 to use a couple of the newer 
> features.   I'd be happy to do what I can to help track this down.  I 
> couldn't find any reference in the list archives about possible fixes 
> since Elliot initially reported the problem with the 2.5.8 release.
> 
> http://www.mail-archive.com/[email-masked]/msg04721.html

Please write to the list.

If you have a time to track down the problem, you may try different daily
snapshots to see when the problem first appeared. Or just setup cvs and
try similar binary search, like this:

  cvs update -D 2003-08-01; make install
  cvs update -D 2003-09-01; make install
  cvs update -D 2003-08-15; make install

> You were right I am using Sun's make, not gmake, my mistake.
> 
> There is no version associated with make, so I've included the pkginfo 
> output.
>  
> $ which make
> /usr/ccs/bin/make
> $ pkginfo -l SUNWxcu4t
>    PKGINST:  SUNWxcu4t
>       NAME:  XCU4 make and sccs utilities
>   CATEGORY:  system
>       ARCH:  sparc
>    VERSION:  5.8,REV=1999.12.12.00.00
[...]

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Wed, 03 Mar 2004 11:39:40 -0500

> result; 2.5.7 is fast; both 2.5.8 and 2.5.9 are dog slow by comparison.

I can confirm the slowness.  (Solaris 8, Ultra 5).

I see it in the menus, the menu appears empty, then the text lines
appear in blocks, slowly.

Same thing in FvwmWinList and FvwmForm.
In all cases, it's the text display that is visibly slow.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 3 Mar 2004 21:08:27 +0100

> 2.5.9 shows the same problem.

Dear Duane, Elliot and any Solaris 8 user,

Can you try to compile 2.5.9 with the --disable-iconv option to configure
(this is not the same thing than --with-iconv-library=no).

Also, can one install gnu libiconv (ftp://ftp.gnu.org/pub/gnu/libiconv/)
and reconfigure and compile fvwm without the  --disable-iconv and
the --with-iconv-library=no. configure should finish with a line like
this:
 
 With Iconv support?                 yes (libiconv)

and *not*

 With Iconv support?                 yes (from C library)

Not sure that the problem is iconv (2.5.7 has in theory iconv
support for Solaris 8).

Regards, Olivier

---

From: Ben Winslow <[email-masked]>
Date: Wed, 03 Mar 2004 15:32:11 -0500

> Switching desks is also slower than on 2.5.7

I'm not sure that it's exactly the same problem, but I've had similar
problems on Linux (x86) with large menus.  WindowList is the worst,
since there's a lot of data (all the window titles, plus geometries),
but the problem occurs with all menus.

I spent some time trying to figure out where all the time was being
spent, and apparently the X server is to blame in my case...  When fvwm
calls XFlush() (I forget where in the source this was, exactly, but I
can try to find it again), a few commands are sent to the server, and
then it hangs for a bit (usually 250-750ms) because the write() blocks. 
I gave up at that point.

-- 
Ben Winslow <[email-masked]>

---

From: Dan Espen <[email-masked]>
Date: Wed, 03 Mar 2004 16:02:40 -0500

> Not sure that the problem is iconv (2.5.7 has in theory iconv

It actually displays something about being disabled by configure.

Adding --disable-iconv fixes the performance problem.

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 3 Mar 2004 22:29:06 +0100

> It actually displays something about being disabled by configure.

Do you mean that with Solaris 8 fvwm 2.5.7 has no iconv support
if you run configure without iconv related option?

Regards, Olivier

---

From: Dan Espen <[email-masked]>
Date: Wed, 03 Mar 2004 17:46:29 -0500

> if you run configure without iconv related option?

I updated to CVS and compiled 2.5.10.

With -disable-iconv it runs fine.
The message configure prints is:
With Iconv support?                 no: Explicitly disabled

Without --disable-iconv it runs really slow.
The message configure prints is:
With Iconv support?                 yes (from C library)

---

From: Duane Paddock - Personal <[email-masked]>
Date: Thu, 4 Mar 2004 08:05:12 -0500 (EST)

> With Iconv support?                 yes (from C library)

I've recompiled the 2.5.9 release tarball with the --disable-iconv flag on
Solaris 8 as well and performance appears to be as fast as 2.5.7.

Thanks to everyone and keep up the great work.  I've been using fvwm since
version 1.24r and love it.

Duane.