Re: Frame size changes

[Chong Yidong <cyd@stupidchicken.com>]

Jan Djärv <jan.h.d@swipnet.se> 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.

If so, how about changing flush_and_sync to be more aggressive, and
demanding a ConfigureNotify before proceeding?

> I've tried many solutions but they all fail in some case or another..
> I think the only proper solution to this is to make Emacs read .emacs
> before it maps the first frame.

This would be a big incompatible change, and at this point in the
release cycle we must exhaust all other workarounds before considering
it.