emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Frame size changes


From: Jan Djärv
Subject: Re: Frame size changes
Date: Sat, 04 Oct 2008 09:19:59 +0200
User-agent: Thunderbird 2.0.0.16 (Macintosh/20080707)



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

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]