GNU bug report logs - #46827
Broken initial size of GTK3 frame

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: 46827 <at> debbugs.gnu.org
Subject: bug#46827: Broken initial size of GTK3 frame
Date: Sun, 28 Feb 2021 10:31:30 +0100

[Message part 1 (text/plain, inline)]

With a GTK3 build I start Emacs with the following initial file
contents:

(customize-set-variable
 'default-frame-alist
 '((cursor-color . "red3")
   (width . 80)
   (height . 32)))

Here this results in a frame that is 36 lines high, has a root window of
31 lines and a minibuffer window of 1 line.  The remaining four lines at
the bottom of the frame are (more or less) empty.

I traced this behavior back to

Fix redisplay performance problems with some fonts
* src/font.c (font_list_entities): Revert part of the changes
introduced on Apr 2, 2014 to fix bug#17125.  It turns out having
zero_vector in the font-cache is an important indication that
cannot be removed.  (Bug#21028)

Commit f3b24e90dc9fad355102e1fdf2828ca33d447a07 does not have the bug
while commit 58430f29968a5661caff630d20dbbe7c864fe08d has it, see the
attached screenshots.

Reverting 58430f29968a5661caff630d20dbbe7c864fe08d with current master
does _not_ fix the bug, so something else must be at play here too.

This is with stable Debian running xfce 4.12 and xfwm4.  I suppose that
various behaviors sketched in Bug#31745 might be related but I have no
idea how the font_list_entities fix could have affected frame creation
in the first place, so these are only wild speculations.  As mentioned
there as well, the bug is GTK3-only, GTK2/Lucid/Motif/None builds are
not affected.

martin

[Initial Frame 58430f29968a5661caff630d20dbbe7c864fe08d.png (image/png, attachment)]

[Initial Frame f3b24e90dc9fad355102e1fdf2828ca33d447a07.png (image/png, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.