[PATCH] problems with initial resizing of the GTK emacs window (needs review)

[PATCH] problems with initial resizing of the GTK emacs window (needs review)

[Michael Stapelberg]

Hi emacs developers,

while debugging a problem with emacs running under the i3 window manager [1],
I think I found a bug in emacs itself.

The symptoms are that an emacs window does not display the whole contents
(the bottom bar is missing, don’t know what you call it exactly) of its
window most of the time (sometimes it works, so it’s a classical race
condition).

Further digging showed that this is a problem because emacs uses the wrong
text_lines for a frame. This seems to be caused by this effect:

In redisplay(), the call graph eventually arrives at update_frame_tool_bar()
which then calls xg_frame_set_char_size. A possible problem here *may* be
(this was my first attempt to patch the problem, but I did not remove the
code before testing my second attempt, so this may or may be not necessary)
that FRAME_LINES(f) and FRAME_COLS(f) is used, even though f->new_text_lines
may not be 0. A patch for this looks like this:

--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -4160,7 +4160,11 @@ update_frame_tool_bar (f)
       && ! FRAME_X_OUTPUT (f)->toolbar_detached)
     {
       FRAME_TOOLBAR_HEIGHT (f) = new_req.height;
-      xg_frame_set_char_size (f, FRAME_COLS (f), FRAME_LINES (f));
+
+      int height = (f->new_text_lines ? f->new_text_lines : FRAME_LINES (f));
+      int width = (f->new_text_cols ? f->new_text_cols : FRAME_COLS (f));
+
+      xg_frame_set_char_size (f, width, height);
     }
 
   UNBLOCK_INPUT;


This alone did not do the trick, however. So, when having a look at
xg_frame_set_char_size(), I noticed that x_wm_size_hint_off() is called. In
x_wm_size_hint_off(), the function flush_and_sync() is called, which in
turn processes *new* events sent by the X server. These events can be
ConfigureNotify events, which lead to recalculation of the number of lines
and columns. While the event is handled properly (say the amount of lines
is recalculated to 37 instead of 40), after returning to
xg_frame_set_char_size(), the gtk window is resized (src/gtkutil.c:737),
which leads to the rendering problems I mentioned.

So, a fix for this could either be:
1) Remove the x_wm_size_hint_off() function entirely, as I don’t see why it
   should be needed. Maybe you can enlighten me on that one.
2) Don’t flush/sync in x_wm_size_hint_off() and ensure that the caller
   flushes/syncs after he did all outstanding requests (in this case,
   resizing the window and changing the rows/cols).

To reproduce the problem, here are the steps I took:
1) Install i3-wm and emacs23 on debian testing (versions are i3-wm 3.d-bf1
   and emacs23 23.1+1-5)
2) Start emacs23-x, see that the bottom bar is not rendered correctly.

Best regards,
Michael

[1] http://i3.zekjur.net/

Re: [PATCH] problems with initial resizing of the GTK emacs window (needs review)

[Michael Stapelberg]

Hi Jan,

Excerpts from Jan D.'s message of Mi Mär 03 08:49:09 +0100 2010:
> Your Emacs seems to be 23.1.  That version will not be updated, we are 
> releasing 23.2 soon.  You should try the trunk version instead.
In the trunk version, this problem does not seem to happen anymore. Thanks
for the hint.

Best regards,
Michael