Jan Djärv <address@hidden> writes:
Emacs calculates the frame size based on some initial font, and sets
wm manager hints based on that (i.e. restricts width/height to a
multiple of the font width/height).
Then Emacs reads .emacs and that changes the font, thus a new size and
a new wm hints is calculated and a new frame size is set.
The window manager applies the size hints and sends configure notify
to Emacs when it does. But if Emacs has read the second font size
before the ConfigureNotify for the first font size changes arrives,
things get strange. The window manager bases the size on the first
font, but Emacs bases it on the second. So when Emacs tries to cope,
it probably does a resize again (because the fonts sizes differ and we
want the frame to be a multiple of the font size). This may lead to
another ConfigureNotify, which may be based on the first or second
font size (resize from Emacs and setting of wm hints does not go the
same way and can be seen out of order by the WM), there is a race
there. And the same thing happens again.
Thanks for the explanation. I think this is indeed the problem.
The straightforward fix is for Emacs to wait until the window manager
gets back with the ConfigureNotify before proceeding. From looking at
gtkutil.c, it seems like you use the function flush_and_sync for a
similar reason. The problem, I'm guessing, is that we aren't guaranteed
that the window manager will have a response ready during the
flush_and_sync.