Re: Frame size changes

["Jan Djärv" <jan.h.d@swipnet.se>]

Chong Yidong skrev:
> 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.

Yes, it is an attempt to make things better.  I also tried turning off wm 
hints while resizing, but that only lead to more problems (i.e. we are not 
guaranteed that the wm gets the off message before the resize, and so on...).


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

In some cases there will be no ConfigureNotify.  If we go down this path, we 
must have a reasonable timeout.  I don't know exactly, but around one second? 
  The thing is when I use Emacs over a slow line, a second is too fast, but 
for normal local uses it will be OK.


> 
>> 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.

Yes I know.  I only mentioned it because I seem to recall some of those Emacs 
variants out there doing this already (Aquaemacs perhaps?).

	Jan D.