set-default-font in emacs21 from breezy is unreasonably slow compared to the version in hoary

[John Steele Scott]

Changing the font in Emacs with set-default-font results in an unreasonable lag
(maybe five seconds) before any result is apparent. With Emacs from hoary, this
problem didn't exist.

The system CPU load does not change during this time, so I'm guessing the
problem is due to some kind of inappropriate timeout somewhere, rather than an
excessive calculation.

[John Steele Scott (toojays)]

For my purposes (changing the default font of Emacs once on startup), there is a
workaround for this bug. If the default font is set on the emacs command line,
like 'emacs -fn "-bitstream-bitstream vera sans
mono-medium-r-normal-*-24-*-100-100-*-*-iso8859-*"', then there is no lag.

The lag only happens when the font is changed from within an already-running
emacs session, by using elisp code, i.e. like (set-default-font
"-bitstream-bitstream vera sans mono-medium-r-normal-*-24-*-100-100-*-*-iso8859-*").

[pbeeson (pbeeson)]

*** Bug 22046 has been marked as a duplicate of this bug. ***

[Rui Matos (tiagomatos)]

Ok I've been suffering this too with emacs-snapshot and it is very annoying.

I did some investigations and found:

1. It only happens under 2 conditions: you have some elisp code changing the default code AND you are running under metacity. I tried running with a simple .xsession with only metacity and an xterm, and launching emacs from there caused the hang. From other window manager (ion3) this doesn't happen. For reference I change my default font with the following code:

(custom-set-faces
 '(default ((t (:stipple nil :background "gray10" :foreground "Ivory" :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 140 :width normal :family "xos4-terminus"))))

commenting that line and running emacs under said environment (metacity only) doesn't trigger the delay.

2. using strace you can see that emacs hangs on 2 calls to poll(). Each call takes about 2 seconds.

I'll continue to investigate but my gut feeling is that this is connected to the recent metacity changes on how new windows are mapped.

[Rui Matos (tiagomatos)]

I reported this on gnome's bugzilla:
http://bugzilla.gnome.org/show_bug.cgi?id=330041

[Scott Anderson (scottanderson)]

I can confirm the command line workaround.

[John Steele Scott (toojays)]

Another workaround is given in the forums at <http://www.ubuntuforums.org/showthread.php?t=183638>:

The suggestion is to add the following at the beginning of your .emacs file:
(modify-frame-parameters nil '((wait-for-wm . nil)))

I haven't tested this myself.

[David Kaplan (dmkaplan)]

I can confirm that this last suggestion fixes the problem (which I have seen in both ubuntu and fedora core 5).

[Mattias Bengtsson (moonlite)]

I can also confirm John Steele Scott's workaround works. (Thanks _a lot_ btw!)

[Steve Kowalik (stevenk)]

This bug was fixed in the 2.16 branch of metacity, but that version didn't hit Edgy, it would have hit Feisty which got the 2.17 (and finally, the 2.18) version of metacity.

[Chris Wagner (chris-wagner)]

This bug still haunts Feisty. I haven't tested Gutsy, yet. Can anyone confirm whether this still exists on Gutsy? If so, we need to re-open this report.

[Adolf Mathias (adolf-mathias-gmail)]

The bug also exists in Intrepid:
a ~5sec delay in poll on the X11 file descriptor
either removing custom-set-faces from my .emacs file or the workaround by John Steele Scott solves the problem.

[Jean-Paul Calderone (exarkun)]

I also have this problem on Hardy with metacity. The wait-for-wm config change works around it.

[Ken Arnold (kenneth-arnold)]

This is still a problem in Jaunty.

The `(modify-frame-parameters nil '((wait-for-wm . nil)))` workaround worked (thanks!).