bug#46827: Broken initial size of GTK3 frame

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

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

[-- Attachment #2: Initial Frame 58430f29968a5661caff630d20dbbe7c864fe08d.png --]
[-- Type: image/png, Size: 42188 bytes --]

[-- Attachment #3: Initial Frame f3b24e90dc9fad355102e1fdf2828ca33d447a07.png --]
[-- Type: image/png, Size: 41407 bytes --]

bug#46827: Broken initial size of GTK3 frame

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 28 Feb 2021 10:31:30 +0100
> 
> 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)

This is very strange, that commit was not supposed to affect frame
dimensions.

Could you please step through the relevant frame-sizing code, and see
how that zero_vector entry in the font-cache causes this problem?

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > This is very strange, that commit was not supposed to affect frame
 > dimensions.
 >
 > Could you please step through the relevant frame-sizing code, and see
 > how that zero_vector entry in the font-cache causes this problem?

The bug seems to be caused by the part of the tool bar code that tries
to detect the height of the tool bar and resize the frame
correspondingly.  Turning off the tool bar makes the bug disappear.

The font.c change garbles the order of the calls of frame resizing
routines.  The following lines produced by `frame--size-history' are
from a "good" run (with the patch I posted earlier here applied)

FRAME-NOTICE-USER	 nil ((cursor-color . red3) (width . 80) (height . 32))
adjust-frame-size-1	 (720 648 720 576) (x-set-frame-parameters 1)
adjust-frame-size-2	 (720 648 720 576) (nil nil)
xg-frame-set-char-size-3 (720 648 720 576) (752 601)
xg-frame-resized	 (720 648 720 576) nil

adjust-frame-size-1	 (720 648 720 576) (change-frame-size 5)
adjust-frame-size-3	 (720 648 720 576) (752 648 752 576)

update-frame-tool-bar	 nil nil
adjust-frame-size-1	 (720 576 720 576) (tool-bar-lines 2)
adjust-frame-size-2	 (720 576 720 576) (nil nil)
xg-frame-set-char-size-3 (720 576 720 576) (752 642)
xg-frame-resized	 (720 576 720 576) nil

while these lines are from a "bad" run (one showing the bug)

FRAME-NOTICE-USER	 nil ((cursor-color . red3) (width . 80) (height . 32))
adjust-frame-size-1	 (720 648 720 576) (x-set-frame-parameters 1)
adjust-frame-size-2	 (720 648 720 576) (nil nil)
xg-frame-set-char-size-3 (720 648 720 576) (752 601)
xg-frame-resized	 (720 648 720 576) nil

update-frame-tool-bar	 nil nil
adjust-frame-size-1	 (720 648 720 648) (tool-bar-lines 2)
adjust-frame-size-2	 (720 648 720 648) (nil nil)
xg-frame-set-char-size-3 (720 648 720 648) (752 714)
xg-frame-resized	 (720 648 720 648) nil

adjust-frame-size-1	 (720 648 720 576) (change-frame-size 5)
adjust-frame-size-3	 (720 648 720 576) (752 648 752 576)

In the bad run, the `change-frame-size' call apparently gets delayed (by
a skipped 'do_pending_window_change' presumably) until after an
update_frame_tool_bar call gets there first.  But so far I have no idea
why font cache issues would have any impact on the order of how things
get executed here.

martin

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > But so far I have no idea
 > why font cache issues would have any impact on the order of how things
 > get executed here.

One clue I found is this: With a "good" run, update_frame_tool_bar gets
called three times with an existing FRAME_GTK_WIDGET, with a "bad" run
it gets called four times before the initial frame appears.  The two
traces below are for Emacs 27 where the first, "good" one is without the
zero_vector assignment and the second, "bad" one is with it.

martin


WITHOUT zero_vector:

Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
4948	  block_input ();
(gdb) bt
#0  0x0000000000621c5c in update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
#1  0x0000000000619fd7 in xg_create_frame_widgets (f=0x1456d70) at ../../src/gtkutil.c:1294
#2  0x00000000005e5607 in x_window (f=0x1456d70) at ../../src/xfns.c:3194
#3  0x00000000005e7eb1 in Fx_create_frame (parms=XIL(0x105e383)) at ../../src/xfns.c:4055
#4  0x00000000007b4852 in funcall_subr (subr=0xf8f0c0 <Sx_create_frame>, numargs=1, args=0x7fffffffb568) at ../../src/eval.c:2872
#5  0x00000000007b431c in Ffuncall (nargs=2, args=0x7fffffffb560) at ../../src/eval.c:2799
#6  0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff3e3ee6c), vector=XIL(0x7ffff3e3df85), maxdepth=make_fixnum(13), args_template=make_fixnum(256), nargs=1, args=0x7fffffffba80) at ../../src/bytecode.c:633
#7  0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3df55), nargs=1, arg_vector=0x7fffffffba78) at ../../src/eval.c:2994
#8  0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffba70) at ../../src/eval.c:2801
#9  0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff3e3eeac), vector=XIL(0x7ffff3e3df15), maxdepth=make_fixnum(3), args_template=make_fixnum(257), nargs=1, args=0x7fffffffc0a0) at ../../src/bytecode.c:633
#10 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3dec5), nargs=1, arg_vector=0x7fffffffc098) at ../../src/eval.c:2994
#11 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffc090) at ../../src/eval.c:2801
#12 0x00000000007b318e in Fapply (nargs=2, args=0x7fffffffc090) at ../../src/eval.c:2386
#13 0x00000000007b4746 in funcall_subr (subr=0xf97cc0 <Sapply>, numargs=2, args=0x7fffffffc090) at ../../src/eval.c:2852
#14 0x00000000007b431c in Ffuncall (nargs=3, args=0x7fffffffc088) at ../../src/eval.c:2799
#15 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff3cfbc7c), vector=XIL(0x7ffff3e3ba7d), maxdepth=make_fixnum(15), args_template=make_fixnum(128), nargs=1, args=0x7fffffffc5c8) at ../../src/bytecode.c:633
#16 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3ba4d), nargs=1, arg_vector=0x7fffffffc5c8) at ../../src/eval.c:2994
#17 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffc5c0) at ../../src/eval.c:2801
#18 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff3e4e5cc), vector=XIL(0x7ffff3c1f21d), maxdepth=make_fixnum(14), args_template=make_fixnum(256), nargs=1, args=0x7fffffffcba8) at ../../src/bytecode.c:633
#19 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3c1f1e5), nargs=1, arg_vector=0x7fffffffcba0) at ../../src/eval.c:2994
#20 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffcb98) at ../../src/eval.c:2801
#21 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff400baa4), vector=XIL(0x7ffff400b9fd), maxdepth=make_fixnum(6), args_template=make_fixnum(0), nargs=0, args=0x7fffffffd090) at ../../src/bytecode.c:633
#22 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff400b9cd), nargs=0, arg_vector=0x7fffffffd090) at ../../src/eval.c:2994
#23 0x00000000007b4360 in Ffuncall (nargs=1, args=0x7fffffffd088) at ../../src/eval.c:2801
#24 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff4011b5c), vector=XIL(0x7ffff400dbdd), maxdepth=make_fixnum(14), args_template=make_fixnum(0), nargs=0, args=0x7fffffffdbd8) at ../../src/bytecode.c:633
#25 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff400dbad), nargs=0, arg_vector=0x7fffffffdbd8) at ../../src/eval.c:2994
#26 0x00000000007b4360 in Ffuncall (nargs=1, args=0x7fffffffdbd0) at ../../src/eval.c:2801
#27 0x0000000000837a9d in exec_byte_code (bytestr=XIL(0x7ffff401282c), vector=XIL(0x7ffff4011d2d), maxdepth=make_fixnum(12), args_template=make_fixnum(0), nargs=0, args=0x7fffffffe220) at ../../src/bytecode.c:633
#28 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff4011cfd), nargs=0, arg_vector=0x7fffffffe220) at ../../src/eval.c:2994
#29 0x00000000007b4bd7 in apply_lambda (fun=XIL(0x7ffff4011cfd), args=XIL(0), count=4) at ../../src/eval.c:2931
#30 0x00000000007b2dd3 in eval_sub (form=XIL(0x7ffff416d89b)) at ../../src/eval.c:2323
#31 0x00000000007b2163 in Feval (form=XIL(0x7ffff416d89b), lexical=XIL(0)) at ../../src/eval.c:2107
#32 0x000000000064af57 in top_level_2 () at ../../src/keyboard.c:1100
#33 0x00000000007b0300 in internal_condition_case (bfun=0x64af34 <top_level_2>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#34 0x000000000064af9f in top_level_1 (ignore=XIL(0)) at ../../src/keyboard.c:1108
#35 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64af59 <top_level_1>, arg=XIL(0)) at ../../src/eval.c:1121
#36 0x000000000064ae7e in command_loop () at ../../src/keyboard.c:1069
#37 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#38 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#39 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066

Lisp Backtrace:
"x-create-frame" (0xffffb568)
"x-create-frame-with-faces" (0xffffba78)
0xf3e3dec0 PVEC_COMPILED
"apply" (0xffffc090)
"frame-creation-function" (0xffffc5c8)
"make-frame" (0xffffcba0)
"frame-initialize" (0xffffd090)
"command-line" (0xffffdbd8)
"normal-top-level" (0xffffe220)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c7e700 (LWP 10050))](running)

Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
4948	  block_input ();
(gdb) bt
#0  0x0000000000621c5c in update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
#1  0x000000000048748f in redisplay_tool_bar (f=0x1456d70) at ../../src/xdisp.c:14161
#2  0x000000000049686c in redisplay_window (window=XIL(0x14bf815), just_this_one_p=false) at ../../src/xdisp.c:19074
#3  0x000000000048beeb in redisplay_window_0 (window=XIL(0x14bf815)) at ../../src/xdisp.c:16328
#4  0x00000000007b03db in internal_condition_case_1 (bfun=0x48bea9 <redisplay_window_0>, arg=XIL(0x14bf815), handlers=XIL(0x7ffff3e9921b), hfun=0x48be71 <redisplay_window_error>) at ../../src/eval.c:1384
#5  0x000000000048be43 in redisplay_windows (window=XIL(0x14bf815)) at ../../src/xdisp.c:16308
#6  0x000000000048bdf5 in redisplay_windows (window=XIL(0x134be45)) at ../../src/xdisp.c:16302
#7  0x000000000048a871 in redisplay_internal () at ../../src/xdisp.c:15776
#8  0x0000000000488458 in redisplay () at ../../src/xdisp.c:14998
#9  0x000000000064f2da in read_char (commandflag=1, map=XIL(0x18b5833), prev_event=XIL(0), used_mouse_menu=0x7fffffffe10f, end_time=0x0) at ../../src/keyboard.c:2493
#10 0x000000000066221b in read_key_sequence (keybuf=0x7fffffffe2a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9554
#11 0x000000000064b7a0 in command_loop_1 () at ../../src/keyboard.c:1350
#12 0x00000000007b0300 in internal_condition_case (bfun=0x64b324 <command_loop_1>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#13 0x000000000064af09 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#14 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64aedc <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1121
#15 0x000000000064aea7 in command_loop () at ../../src/keyboard.c:1070
#16 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c7e700 (LWP 10050))](running)

Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
4948	  block_input ();
(gdb) bt
#0  0x0000000000621c5c in update_frame_tool_bar (f=0x1456d70) at ../../src/gtkutil.c:4948
#1  0x000000000048748f in redisplay_tool_bar (f=0x1456d70) at ../../src/xdisp.c:14161
#2  0x000000000049686c in redisplay_window (window=XIL(0x14bf815), just_this_one_p=false) at ../../src/xdisp.c:19074
#3  0x000000000048beeb in redisplay_window_0 (window=XIL(0x14bf815)) at ../../src/xdisp.c:16328
#4  0x00000000007b03db in internal_condition_case_1 (bfun=0x48bea9 <redisplay_window_0>, arg=XIL(0x14bf815), handlers=XIL(0x7ffff3e9921b), hfun=0x48be71 <redisplay_window_error>) at ../../src/eval.c:1384
#5  0x000000000048be43 in redisplay_windows (window=XIL(0x14bf815)) at ../../src/xdisp.c:16308
#6  0x000000000048bdf5 in redisplay_windows (window=XIL(0x134be45)) at ../../src/xdisp.c:16302
#7  0x000000000048a871 in redisplay_internal () at ../../src/xdisp.c:15776
#8  0x0000000000488458 in redisplay () at ../../src/xdisp.c:14998
#9  0x000000000064f2da in read_char (commandflag=1, map=XIL(0x18b5833), prev_event=XIL(0), used_mouse_menu=0x7fffffffe10f, end_time=0x0) at ../../src/keyboard.c:2493
#10 0x000000000066221b in read_key_sequence (keybuf=0x7fffffffe2a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9554
#11 0x000000000064b7a0 in command_loop_1 () at ../../src/keyboard.c:1350
#12 0x00000000007b0300 in internal_condition_case (bfun=0x64b324 <command_loop_1>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#13 0x000000000064af09 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#14 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64aedc <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1121
#15 0x000000000064aea7 in command_loop () at ../../src/keyboard.c:1070
#16 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c7e700 (LWP 10050))](running)


WITH zero_vector:

Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
4948	  block_input ();
(gdb) bt
#0  0x0000000000621c5c in update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
#1  0x0000000000619fd7 in xg_create_frame_widgets (f=0x14369f0) at ../../src/gtkutil.c:1294
#2  0x00000000005e5607 in x_window (f=0x14369f0) at ../../src/xfns.c:3194
#3  0x00000000005e7eb1 in Fx_create_frame (parms=XIL(0x105e383)) at ../../src/xfns.c:4055
#4  0x00000000007b4852 in funcall_subr (subr=0xf8f0c0 <Sx_create_frame>, numargs=1, args=0x7fffffffb568) at ../../src/eval.c:2872
#5  0x00000000007b431c in Ffuncall (nargs=2, args=0x7fffffffb560) at ../../src/eval.c:2799
#6  0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff3e3ee6c), vector=XIL(0x7ffff3e3df85), maxdepth=make_fixnum(13), args_template=make_fixnum(256), nargs=1, args=0x7fffffffba80) at ../../src/bytecode.c:633
#7  0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3df55), nargs=1, arg_vector=0x7fffffffba78) at ../../src/eval.c:2994
#8  0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffba70) at ../../src/eval.c:2801
#9  0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff3e3eeac), vector=XIL(0x7ffff3e3df15), maxdepth=make_fixnum(3), args_template=make_fixnum(257), nargs=1, args=0x7fffffffc0a0) at ../../src/bytecode.c:633
#10 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3dec5), nargs=1, arg_vector=0x7fffffffc098) at ../../src/eval.c:2994
#11 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffc090) at ../../src/eval.c:2801
#12 0x00000000007b318e in Fapply (nargs=2, args=0x7fffffffc090) at ../../src/eval.c:2386
#13 0x00000000007b4746 in funcall_subr (subr=0xf97cc0 <Sapply>, numargs=2, args=0x7fffffffc090) at ../../src/eval.c:2852
#14 0x00000000007b431c in Ffuncall (nargs=3, args=0x7fffffffc088) at ../../src/eval.c:2799
#15 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff3cfbc7c), vector=XIL(0x7ffff3e3ba7d), maxdepth=make_fixnum(15), args_template=make_fixnum(128), nargs=1, args=0x7fffffffc5c8) at ../../src/bytecode.c:633
#16 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3e3ba4d), nargs=1, arg_vector=0x7fffffffc5c8) at ../../src/eval.c:2994
#17 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffc5c0) at ../../src/eval.c:2801
#18 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff3e4e5cc), vector=XIL(0x7ffff3c1f21d), maxdepth=make_fixnum(14), args_template=make_fixnum(256), nargs=1, args=0x7fffffffcba8) at ../../src/bytecode.c:633
#19 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff3c1f1e5), nargs=1, arg_vector=0x7fffffffcba0) at ../../src/eval.c:2994
#20 0x00000000007b4360 in Ffuncall (nargs=2, args=0x7fffffffcb98) at ../../src/eval.c:2801
#21 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff400baa4), vector=XIL(0x7ffff400b9fd), maxdepth=make_fixnum(6), args_template=make_fixnum(0), nargs=0, args=0x7fffffffd090) at ../../src/bytecode.c:633
#22 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff400b9cd), nargs=0, arg_vector=0x7fffffffd090) at ../../src/eval.c:2994
#23 0x00000000007b4360 in Ffuncall (nargs=1, args=0x7fffffffd088) at ../../src/eval.c:2801
#24 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff4011b5c), vector=XIL(0x7ffff400dbdd), maxdepth=make_fixnum(14), args_template=make_fixnum(0), nargs=0, args=0x7fffffffdbd8) at ../../src/bytecode.c:633
#25 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff400dbad), nargs=0, arg_vector=0x7fffffffdbd8) at ../../src/eval.c:2994
#26 0x00000000007b4360 in Ffuncall (nargs=1, args=0x7fffffffdbd0) at ../../src/eval.c:2801
#27 0x0000000000837a86 in exec_byte_code (bytestr=XIL(0x7ffff401282c), vector=XIL(0x7ffff4011d2d), maxdepth=make_fixnum(12), args_template=make_fixnum(0), nargs=0, args=0x7fffffffe220) at ../../src/bytecode.c:633
#28 0x00000000007b4fa0 in funcall_lambda (fun=XIL(0x7ffff4011cfd), nargs=0, arg_vector=0x7fffffffe220) at ../../src/eval.c:2994
#29 0x00000000007b4bd7 in apply_lambda (fun=XIL(0x7ffff4011cfd), args=XIL(0), count=4) at ../../src/eval.c:2931
#30 0x00000000007b2dd3 in eval_sub (form=XIL(0x7ffff416d89b)) at ../../src/eval.c:2323
#31 0x00000000007b2163 in Feval (form=XIL(0x7ffff416d89b), lexical=XIL(0)) at ../../src/eval.c:2107
#32 0x000000000064af57 in top_level_2 () at ../../src/keyboard.c:1100
#33 0x00000000007b0300 in internal_condition_case (bfun=0x64af34 <top_level_2>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#34 0x000000000064af9f in top_level_1 (ignore=XIL(0)) at ../../src/keyboard.c:1108
#35 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64af59 <top_level_1>, arg=XIL(0)) at ../../src/eval.c:1121
#36 0x000000000064ae7e in command_loop () at ../../src/keyboard.c:1069
#37 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#38 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#39 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066

Lisp Backtrace:
"x-create-frame" (0xffffb568)
"x-create-frame-with-faces" (0xffffba78)
0xf3e3dec0 PVEC_COMPILED
"apply" (0xffffc090)
"frame-creation-function" (0xffffc5c8)
"make-frame" (0xffffcba0)
"frame-initialize" (0xffffd090)
"command-line" (0xffffdbd8)
"normal-top-level" (0xffffe220)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c5d700 (LWP 10301))](running)

Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
4948	  block_input ();
(gdb) bt
#0  0x0000000000621c5c in update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
#1  0x000000000048748f in redisplay_tool_bar (f=0x14369f0) at ../../src/xdisp.c:14161
#2  0x000000000049686c in redisplay_window (window=XIL(0x149feb5), just_this_one_p=false) at ../../src/xdisp.c:19074
#3  0x000000000048beeb in redisplay_window_0 (window=XIL(0x149feb5)) at ../../src/xdisp.c:16328
#4  0x00000000007b03db in internal_condition_case_1 (bfun=0x48bea9 <redisplay_window_0>, arg=XIL(0x149feb5), handlers=XIL(0x7ffff3e9921b), hfun=0x48be71 <redisplay_window_error>) at ../../src/eval.c:1384
#5  0x000000000048be43 in redisplay_windows (window=XIL(0x149feb5)) at ../../src/xdisp.c:16308
#6  0x000000000048bdf5 in redisplay_windows (window=XIL(0x135ee55)) at ../../src/xdisp.c:16302
#7  0x000000000048a871 in redisplay_internal () at ../../src/xdisp.c:15776
#8  0x0000000000488458 in redisplay () at ../../src/xdisp.c:14998
#9  0x000000000064f2da in read_char (commandflag=1, map=XIL(0x1897353), prev_event=XIL(0), used_mouse_menu=0x7fffffffe10f, end_time=0x0) at ../../src/keyboard.c:2493
#10 0x000000000066221b in read_key_sequence (keybuf=0x7fffffffe2a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9554
#11 0x000000000064b7a0 in command_loop_1 () at ../../src/keyboard.c:1350
#12 0x00000000007b0300 in internal_condition_case (bfun=0x64b324 <command_loop_1>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#13 0x000000000064af09 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#14 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64aedc <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1121
#15 0x000000000064aea7 in command_loop () at ../../src/keyboard.c:1070
#16 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c5d700 (LWP 10301))](running)

Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
4948	  block_input ();
(gdb) bt
#0  0x0000000000621c5c in update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
#1  0x000000000048748f in redisplay_tool_bar (f=0x14369f0) at ../../src/xdisp.c:14161
#2  0x000000000049686c in redisplay_window (window=XIL(0x149feb5), just_this_one_p=false) at ../../src/xdisp.c:19074
#3  0x000000000048beeb in redisplay_window_0 (window=XIL(0x149feb5)) at ../../src/xdisp.c:16328
#4  0x00000000007b03db in internal_condition_case_1 (bfun=0x48bea9 <redisplay_window_0>, arg=XIL(0x149feb5), handlers=XIL(0x7ffff3e9921b), hfun=0x48be71 <redisplay_window_error>) at ../../src/eval.c:1384
#5  0x000000000048be43 in redisplay_windows (window=XIL(0x149feb5)) at ../../src/xdisp.c:16308
#6  0x000000000048bdf5 in redisplay_windows (window=XIL(0x135ee55)) at ../../src/xdisp.c:16302
#7  0x000000000048a871 in redisplay_internal () at ../../src/xdisp.c:15776
#8  0x0000000000488458 in redisplay () at ../../src/xdisp.c:14998
#9  0x000000000064f2da in read_char (commandflag=1, map=XIL(0x1897353), prev_event=XIL(0), used_mouse_menu=0x7fffffffe10f, end_time=0x0) at ../../src/keyboard.c:2493
#10 0x000000000066221b in read_key_sequence (keybuf=0x7fffffffe2a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9554
#11 0x000000000064b7a0 in command_loop_1 () at ../../src/keyboard.c:1350
#12 0x00000000007b0300 in internal_condition_case (bfun=0x64b324 <command_loop_1>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#13 0x000000000064af09 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#14 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64aedc <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1121
#15 0x000000000064aea7 in command_loop () at ../../src/keyboard.c:1070
#16 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c5d700 (LWP 10301))](running)

Thread 1 "emacs" hit Breakpoint 3, update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
4948	  block_input ();
(gdb) bt
#0  0x0000000000621c5c in update_frame_tool_bar (f=0x14369f0) at ../../src/gtkutil.c:4948
#1  0x000000000048748f in redisplay_tool_bar (f=0x14369f0) at ../../src/xdisp.c:14161
#2  0x000000000049686c in redisplay_window (window=XIL(0x149feb5), just_this_one_p=false) at ../../src/xdisp.c:19074
#3  0x000000000048beeb in redisplay_window_0 (window=XIL(0x149feb5)) at ../../src/xdisp.c:16328
#4  0x00000000007b03db in internal_condition_case_1 (bfun=0x48bea9 <redisplay_window_0>, arg=XIL(0x149feb5), handlers=XIL(0x7ffff3e9921b), hfun=0x48be71 <redisplay_window_error>) at ../../src/eval.c:1384
#5  0x000000000048be43 in redisplay_windows (window=XIL(0x149feb5)) at ../../src/xdisp.c:16308
#6  0x000000000048bdf5 in redisplay_windows (window=XIL(0x135ee55)) at ../../src/xdisp.c:16302
#7  0x000000000048a871 in redisplay_internal () at ../../src/xdisp.c:15776
#8  0x0000000000488458 in redisplay () at ../../src/xdisp.c:14998
#9  0x000000000064f2da in read_char (commandflag=1, map=XIL(0x1897353), prev_event=XIL(0), used_mouse_menu=0x7fffffffe10f, end_time=0x0) at ../../src/keyboard.c:2493
#10 0x000000000066221b in read_key_sequence (keybuf=0x7fffffffe2a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9554
#11 0x000000000064b7a0 in command_loop_1 () at ../../src/keyboard.c:1350
#12 0x00000000007b0300 in internal_condition_case (bfun=0x64b324 <command_loop_1>, handlers=XIL(0x90), hfun=0x64a933 <cmd_error>) at ../../src/eval.c:1360
#13 0x000000000064af09 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#14 0x00000000007af7b4 in internal_catch (tag=XIL(0xd110), func=0x64aedc <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1121
#15 0x000000000064aea7 in command_loop () at ../../src/keyboard.c:1070
#16 0x000000000064a41a in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000000000064a612 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x0000000000640a1b in main (argc=4, argv=0x7fffffffe798) at ../../src/emacs.c:2066

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) c
Continuing.
[Switching to thread 4 (Thread 0x7ffff1c5d700 (LWP 10301))](running)

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

Re-sending this since it apparently got lost by the bug tracker:

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

It turns out that the "something else" is just that

              /* Querying further backends can be very slow, so we only do
                 it if the user has explicitly requested it (Bug#43177).  */
              if (query_all_font_backends == false)
                break;

The attached patch reverting 58430f29968a5661caff630d20dbbe7c864fe08d
and removing the entity above fixes the bug on master.

martin


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: font.c.diff --]
[-- Type: text/x-patch; name="font.c.diff", Size: 1793 bytes --]

diff --git a/src/font.c b/src/font.c
index a59ebe216b..1bb1eb29a5 100644
--- a/src/font.c
+++ b/src/font.c
@@ -2797,34 +2797,24 @@ font_list_entities (struct frame *f, Lisp_Object spec)
 	  val = XCDR (val);
 	else
 	  {
-	    Lisp_Object copy;
-
 	    val = (driver_list->driver->list) (f, scratch_font_spec);
-	    /* We put zero_vector in the font-cache to indicate that
-	       no fonts matching SPEC were found on the system.
-	       Failure to have this indication in the font cache can
-	       cause severe performance degradation in some rare
-	       cases, see bug#21028.  */
-	    if (NILP (val))
-	      val = zero_vector;
-	    else
-	      val = Fvconcat (1, &val);
-	    copy = copy_font_spec (scratch_font_spec);
-	    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
-	    XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache)));
+	    if (!NILP (val))
+	      {
+		Lisp_Object copy = copy_font_spec (scratch_font_spec);
+
+		val = Fvconcat (1, &val);
+		ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
+		XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache)));
+	      }
 	  }
-	if (ASIZE (val) > 0
+
+	if (VECTORP (val) && ASIZE (val) > 0
 	    && (need_filtering
 		|| ! NILP (Vface_ignored_fonts)))
 	  val = font_delete_unmatched (val, need_filtering ? spec : Qnil, size);
-	if (ASIZE (val) > 0)
-          {
-            list = Fcons (val, list);
-            /* Querying further backends can be very slow, so we only do
-               it if the user has explicitly requested it (Bug#43177).  */
-            if (query_all_font_backends == false)
-              break;
-          }
+
+	if (VECTORP (val) && ASIZE (val) > 0)
+	  list = Fcons (val, list);
       }

   list = Fnreverse (list);

bug#46827: Broken initial size of GTK3 frame

[Robert Pluim]

>>>>> On Mon, 1 Mar 2021 09:31:20 +0100, martin rudalics <rudalics@gmx.at> said:

    martin> Re-sending this since it apparently got lost by the bug tracker:
    >> Reverting 58430f29968a5661caff630d20dbbe7c864fe08d with current master
    >> does _not_ fix the bug, so something else must be at play here too.

Iʼll just say I donʼt see this with Gnome on Debian testing, with
either emacs-27 or master, so once again itʼs window manager
dependent.

    martin> It turns out that the "something else" is just that

    martin>              /* Querying further backends can be very slow, so we only do
    martin>                 it if the user has explicitly requested it (Bug#43177).  */
    martin>              if (query_all_font_backends == false)
    martin>                break;

    martin> The attached patch reverting 58430f29968a5661caff630d20dbbe7c864fe08d
    martin> and removing the entity above fixes the bug on master.

Iʼm surprised that querying another font backend when we've already
found a font causes frame sizing issues like this. Do we understand
the cause here?

We can revert the bug#43177 fix of course, but perhaps we should make
it conditional on !GTK3 || PGTK or something?

Robert
-- 

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > Iʼll just say I donʼt see this with Gnome on Debian testing, with
 > either emacs-27 or master, so once again itʼs window manager
 > dependent.

What does (frame-height) give for your frame?

 > Iʼm surprised that querying another font backend when we've already
 > found a font causes frame sizing issues like this. Do we understand
 > the cause here?

No.  All I can say is that it is tool bar related.

 > We can revert the bug#43177 fix of course, but perhaps we should make
 > it conditional on !GTK3 || PGTK or something?

First I'd like to fix the behavior for Emacs 27, conceptually at least.
Then we can discuss Bug#43177.

martin

bug#46827: Broken initial size of GTK3 frame

[Robert Pluim]

>>>>> On Mon, 1 Mar 2021 13:38:58 +0100, martin rudalics <rudalics@gmx.at> said:

    >> Iʼll just say I donʼt see this with Gnome on Debian testing, with
    >> either emacs-27 or master, so once again itʼs window manager
    >> dependent.

    martin> What does (frame-height) give for your frame?

30. A lucid build gives me 31, so itʼs no better. (all emacs-27)

Iʼll install xfwm4 and see what happens.

    >> Iʼm surprised that querying another font backend when we've already
    >> found a font causes frame sizing issues like this. Do we understand
    >> the cause here?

    martin> No.  All I can say is that it is tool bar related.

<wild stab in the dark> What happens if you disable the code that
displays text labels in the tool bar:

diff --git a/src/gtkutil.c b/src/gtkutil.c
index 825fbe1d45..425b0727e9 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -4708,8 +4708,6 @@ xg_make_tool_item (struct frame *f,
 
   if (wimage && !text_image)
     gtk_box_pack_start (GTK_BOX (vb), wimage, TRUE, TRUE, 0);
-  if (label)
-    gtk_box_pack_start (GTK_BOX (vb), gtk_label_new (label), TRUE, TRUE, 0);
   if (wimage && text_image)
     gtk_box_pack_start (GTK_BOX (vb), wimage, TRUE, TRUE, 0);
 
@@ -4723,7 +4721,7 @@ xg_make_tool_item (struct frame *f,
   gtk_container_add (GTK_CONTAINER (weventbox), wb);
   gtk_container_add (GTK_CONTAINER (ti), weventbox);
 
-  if (wimage || label)
+  if (wimage)
     {
       intptr_t ii = i;
       gpointer gi = (gpointer) ii;

    >> We can revert the bug#43177 fix of course, but perhaps we should make
    >> it conditional on !GTK3 || PGTK or something?

    martin> First I'd like to fix the behavior for Emacs 27, conceptually at least.
    martin> Then we can discuss Bug#43177.

Works for me.

Robert
-- 

bug#46827: Broken initial size of GTK3 frame

[Robert Pluim]

>>>>> On Mon, 01 Mar 2021 14:30:58 +0100, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Mon, 1 Mar 2021 13:38:58 +0100, martin rudalics <rudalics@gmx.at> said:
    >>> Iʼll just say I donʼt see this with Gnome on Debian testing, with
    >>> either emacs-27 or master, so once again itʼs window manager
    >>> dependent.

    martin> What does (frame-height) give for your frame?

    Robert> 30. A lucid build gives me 31, so itʼs no better. (all emacs-27)

    Robert> Iʼll install xfwm4 and see what happens.

With "xfwm4/testing,now 4.16.1-1 amd64" I donʼt see any issues with
the frame (and it gives me a frame height of 32).

Robert
-- 

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > With "xfwm4/testing,now 4.16.1-1 amd64" I donʼt see any issues with
 > the frame (and it gives me a frame height of 32).

Hmm... interesting.  Which GTK version is this?  And what about the
other builds?

martin

bug#46827: Broken initial size of GTK3 frame

[Robert Pluim]

>>>>> On Mon, 1 Mar 2021 19:03:44 +0100, martin rudalics <rudalics@gmx.at> said:

    >> With "xfwm4/testing,now 4.16.1-1 amd64" I donʼt see any issues with
    >> the frame (and it gives me a frame height of 32).

    martin> Hmm... interesting.  Which GTK version is this?  And what about the
    martin> other builds?

3.24.24. The lucid build gives me a frame height of 32 as well.

Interestingly, if I run the gtk build under xfwm4 without its dumpfile
present, I do sometimes see the frame issue you reported, which
suggests itʼs a timing issue somewhere.

Robert
-- 

bug#46827: Broken initial size of GTK3 frame

[Robert Pluim]

>>>>> On Mon, 01 Mar 2021 19:23:21 +0100, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Mon, 1 Mar 2021 19:03:44 +0100, martin rudalics <rudalics@gmx.at> said:
    >>> With "xfwm4/testing,now 4.16.1-1 amd64" I donʼt see any issues with
    >>> the frame (and it gives me a frame height of 32).

    martin> Hmm... interesting.  Which GTK version is this?  And what about the
    martin> other builds?

    Robert> 3.24.24. The lucid build gives me a frame height of 32 as well.

    Robert> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
    Robert> present, I do sometimes see the frame issue you reported, which
    Robert> suggests itʼs a timing issue somewhere.

And in fact even with the dumpfile I see this in emacs-27 and
emacs-master, just not consistently.

Robert
-- 

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > And in fact even with the dumpfile I see this in emacs-27 and
 > emacs-master, just not consistently.

I see it consistently here and the same with GNOME 3.34.2.  But the same
GTK3 build works correctly here with plasma 5.17.5 which, OTOH, makes my
Lucid frame only 31 lines high.

So we could dismiss the frame height differences as WM idiosyncrasies as
you said but that unhandled space at the bottom is too ugly.

martin

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > Interestingly, if I run the gtk build under xfwm4 without its dumpfile
 > present, I do sometimes see the frame issue you reported, which
 > suggests itʼs a timing issue somewhere.

How do you run a build without the dump file present?

martin

bug#46827: Broken initial size of GTK3 frame

[Robert Pluim]

>>>>> On Mon, 1 Mar 2021 20:04:47 +0100, martin rudalics <rudalics@gmx.at> said:

    >> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
    >> present, I do sometimes see the frame issue you reported, which
    >> suggests itʼs a timing issue somewhere.

    martin> How do you run a build without the dump file present?

You rename the emacs binary to something other than emacs (although
renaming the emacs.pdmp file would also work).

Robert
-- 

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >      martin> How do you run a build without the dump file present?
 >
 > You rename the emacs binary to something other than emacs (although
 > renaming the emacs.pdmp file would also work).

Neither of these work here.  Maybe because I'm building out of tree.

martin

bug#46827: Broken initial size of GTK3 frame

[Stephen Berman]

On Mon, 01 Mar 2021 19:23:21 +0100 Robert Pluim <rpluim@gmail.com> wrote:

>>>>>> On Mon, 1 Mar 2021 19:03:44 +0100, martin rudalics <rudalics@gmx.at> said:
>
>     >> With "xfwm4/testing,now 4.16.1-1 amd64" I donʼt see any issues with
>     >> the frame (and it gives me a frame height of 32).
>
>     martin> Hmm... interesting.  Which GTK version is this?  And what about the
>     martin> other builds?
>
> 3.24.24. The lucid build gives me a frame height of 32 as well.
>
> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
> present, I do sometimes see the frame issue you reported, which
> suggests itʼs a timing issue somewhere.

Evidence in favor of that suggestion may be the following observations:
I can reliably reproduce the problematic display (on xfwm4-4.14.1 with
GTK+ 3.24.17) with the first invocation below, but not with the second
invocation:

$ emacs-master -Q --eval "(customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32)))"

$ emacs-master -Q --eval "(progn (sleep-for .1) (customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32))))"

Yet I can also reproduce the display problem with the following
invocation:

$ emacs-master -Q --eval "(progn (sit-for .1) (customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32))))"

Steve Berman

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
 >> present, I do sometimes see the frame issue you reported, which
 >> suggests itʼs a timing issue somewhere.
 >
 > Evidence in favor of that suggestion may be the following observations:
 > I can reliably reproduce the problematic display (on xfwm4-4.14.1 with
 > GTK+ 3.24.17) with the first invocation below, but not with the second
 > invocation:

Why is this evidence in favor of the above suggestion?

 > $ emacs-master -Q --eval "(customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32)))"
 >
 > $ emacs-master -Q --eval "(progn (sleep-for .1) (customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32))))"
 >
 > Yet I can also reproduce the display problem with the following
 > invocation:
 >
 > $ emacs-master -Q --eval "(progn (sit-for .1) (customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32))))"

Both `sleep-for' and `sit-for' with an abismal small argument work here,
0 does not.  So the problem still seems that redisplay misses a pending
window change.  I have no idea why `sleep-for' and `sit-for' behave
differently for you though.

martin

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

 > So the problem still seems that redisplay misses a pending
 > window change.

Confirmed meanwhile.  The attached patch fixes the problem here.  Eli
will tell use whether we can put that do_pending_window_change in some
suitable safe place within redisplay_internal.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xdisp.c.diff --]
[-- Type: text/x-patch; name="xdisp.c.diff", Size: 417 bytes --]

diff --git a/src/xdisp.c b/src/xdisp.c
index cac3195170..8bbcc2b7ec 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -15500,6 +15500,8 @@ redisplay_internal (void)
   consider_all_windows_p = (update_mode_lines
 			    || windows_or_buffers_changed);

+  do_pending_window_change (true);
+
 #define AINC(a,i)							\
   {									\
     Lisp_Object entry = Fgethash (make_fixnum (i), a, make_fixnum (0));	\

bug#46827: Broken initial size of GTK3 frame

[Robert Pluim]

>>>>> On Tue, 2 Mar 2021 10:07:02 +0100, martin rudalics <rudalics@gmx.at> said:

    >> So the problem still seems that redisplay misses a pending
    >> window change.

    martin> Confirmed meanwhile.  The attached patch fixes the problem here.  Eli
    martin> will tell use whether we can put that do_pending_window_change in some
    martin> suitable safe place within redisplay_internal.

It fixes it for me as well in emacs-27 and master (and the
frame-height is correct), and doesnʼt appear to have broken anything
under Gnome.

Robert
-- 

bug#46827: Broken initial size of GTK3 frame

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 2 Mar 2021 10:07:02 +0100
> Cc: 46827@debbugs.gnu.org
> 
>  > So the problem still seems that redisplay misses a pending
>  > window change.
> 
> Confirmed meanwhile.  The attached patch fixes the problem here.  Eli
> will tell use whether we can put that do_pending_window_change in some
> suitable safe place within redisplay_internal.

What's wrong with this place?  But please note that after calling
do_pending_window_change you need to perform the "maybe the selected
window changed" dance we do after other similar calls.

Otherwise, I'm okay with this change, but only on master.  Emacs 27.2
will have to make do with what we have now.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

 > What's wrong with this place?

Actually, it's not needed.  I just have to call do_pending_window_change
_after_ updating the tool bar as in the attached patch.

 > But please note that after calling
 > do_pending_window_change you need to perform the "maybe the selected
 > window changed" dance we do after other similar calls.

I suppose the

       do_pending_window_change could change the selected_window due to
       frame resizing which makes the selected window too small.

is some sort of cargo cult now.  While frame resizing can make the
selected window small, it will neither remove nor change it.

But since the menu and tool bar code _can_ change the selected window
we'll still have to cater for it.

 > Otherwise, I'm okay with this change, but only on master.  Emacs 27.2
 > will have to make do with what we have now.

Don't worry.  Even on master we could condition it on GTK3.  I'd just
want to find out why it works around the problem in the first place.

And I have a second, similar GTK3-only frame resizing problem with a
similar effect that, however, becomes virulent only after resizing a
frame manually with the mouse.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xdisp.c.diff --]
[-- Type: text/x-patch; name="xdisp.c.diff", Size: 826 bytes --]

diff --git a/src/xdisp.c b/src/xdisp.c
index cc0a689ba3..827a484fc9 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -15650,9 +15650,6 @@ redisplay_internal (void)
       clear_desired_matrices (f);
     }

-  /* Notice any pending interrupt request to change frame size.  */
-  do_pending_window_change (true);
-
   /* Clear frames marked as garbaged.  */
   clear_garbaged_frames ();

@@ -15660,6 +15657,9 @@ redisplay_internal (void)
   if (NILP (Vmemory_full))
     prepare_menu_bars ();

+  /* Notice any pending interrupt request to change frame size.  */
+  do_pending_window_change (true);
+
   /* do_pending_window_change could change the selected_window due to
      frame resizing which makes the selected window too small.
      prepare_menu_bars may call lisp hooks and hence also change the

bug#46827: Broken initial size of GTK3 frame

[Eli Zaretskii]

> Cc: stephen.berman@gmx.net, rpluim@gmail.com, 46827@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 2 Mar 2021 17:07:16 +0100
> 
>  > What's wrong with this place?
> 
> Actually, it's not needed.  I just have to call do_pending_window_change
> _after_ updating the tool bar as in the attached patch.

Thanks, but is there any reason to remove the call before updating the
tool bar?  You see, I believe one of the reasons for the need to
clear_garbaged_frames is that call you suggest to remove.  Why not
leave it there, and _add_ one more call after prepare_menu_bars (and
perhaps condition it on the same condition as prepare_menu_bars)?

>  > But please note that after calling
>  > do_pending_window_change you need to perform the "maybe the selected
>  > window changed" dance we do after other similar calls.
> 
> I suppose the
> 
>        do_pending_window_change could change the selected_window due to
>        frame resizing which makes the selected window too small.
> 
> is some sort of cargo cult now.  While frame resizing can make the
> selected window small, it will neither remove nor change it.

Never-ever?

>  > Otherwise, I'm okay with this change, but only on master.  Emacs 27.2
>  > will have to make do with what we have now.
> 
> Don't worry.  Even on master we could condition it on GTK3.  I'd just
> want to find out why it works around the problem in the first place.

I suspect that the code which calculates the dimensions of the tool
bar causes this.

> And I have a second, similar GTK3-only frame resizing problem with a
> similar effect that, however, becomes virulent only after resizing a
> frame manually with the mouse.

Fun.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

 > Thanks, but is there any reason to remove the call before updating the
 > tool bar?  You see, I believe one of the reasons for the need to
 > clear_garbaged_frames is that call you suggest to remove.  Why not
 > leave it there, and _add_ one more call after prepare_menu_bars (and
 > perhaps condition it on the same condition as prepare_menu_bars)?

We can obviously do that (see attached patch).  But is there any reason
we cannot run the

   do_pending_window_change (true);
   clear_garbaged_frames ();

_after_ the

       prepare_menu_bars ();
       do_pending_window_change (true);

block?

In either case, the more I look into this, the more things confuse me.
For example, why does

	  if (!must_finish)
	    {
	      do_pending_window_change (true);
	      /* If selected_window changed, redisplay again.  */
	      if (WINDOWP (selected_window)
		  && (w = XWINDOW (selected_window)) != sw)
		goto retry;

not check for windows_or_buffers_changed too just as we do after the
third do_pending_window_change call?  But then I don't understand why we
check for windows_or_buffers_changed at all.  adjust_frame_size doesn't
set that IIUC but it does garbage the frame - why don't we check that in
redisplay_internal?

 >> While frame resizing can make the
 >> selected window small, it will neither remove nor change it.
 >
 > Never-ever?

Never-ever.  Fdelete_window_internal, Fdelete_other_windows_internal and
Fset_window_configuration are the only functions allowed to delete
windows.  run_window_change_functions could delete the selected window
so we probably should do the w == sw check after that now.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xdisp.c.diff --]
[-- Type: text/x-patch; name="xdisp.c.diff", Size: 586 bytes --]

diff --git a/src/xdisp.c b/src/xdisp.c
index cc0a689ba3..78f25af991 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -15658,7 +15658,13 @@ redisplay_internal (void)

   /* Build menubar and tool-bar items.  */
   if (NILP (Vmemory_full))
-    prepare_menu_bars ();
+    {
+      prepare_menu_bars ();
+
+      /* Once more taking into account the new tool bar height
+	 (Bug#46827).  */
+      do_pending_window_change (true);
+    }

   /* do_pending_window_change could change the selected_window due to
      frame resizing which makes the selected window too small.

bug#46827: Broken initial size of GTK3 frame

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Cc: stephen.berman@gmx.net, rpluim@gmail.com, 46827@debbugs.gnu.org
> Date: Wed, 3 Mar 2021 09:48:16 +0100
> 
>  > Thanks, but is there any reason to remove the call before updating the
>  > tool bar?  You see, I believe one of the reasons for the need to
>  > clear_garbaged_frames is that call you suggest to remove.  Why not
>  > leave it there, and _add_ one more call after prepare_menu_bars (and
>  > perhaps condition it on the same condition as prepare_menu_bars)?
> 
> We can obviously do that (see attached patch).  But is there any reason
> we cannot run the
> 
>    do_pending_window_change (true);
>    clear_garbaged_frames ();
> 
> _after_ the
> 
>        prepare_menu_bars ();
>        do_pending_window_change (true);
> 
> block?

I have no idea, and don't know how to check that.  We could try, and
then be ready to fix any adverse effects this could cause.

> In either case, the more I look into this, the more things confuse me.
> For example, why does
> 
> 	  if (!must_finish)
> 	    {
> 	      do_pending_window_change (true);
> 	      /* If selected_window changed, redisplay again.  */
> 	      if (WINDOWP (selected_window)
> 		  && (w = XWINDOW (selected_window)) != sw)
> 		goto retry;
> 
> not check for windows_or_buffers_changed too just as we do after the
> third do_pending_window_change call?

Because going to 'retry' will eventually make that check again.  Or
maybe I don't understand what exactly are you asking here?

> But then I don't understand why we
> check for windows_or_buffers_changed at all.  adjust_frame_size doesn't
> set that IIUC but it does garbage the frame - why don't we check that in
> redisplay_internal?

Sorry, I don't understand the question.  We _are_ talking about
redisplay_internal, right? and redisplay_internal does check
windows_or_buffers_changed, right? so what do you mean by "why don't
we check that in redisplay_internal"? and what is "that" in this case?

>  >> While frame resizing can make the
>  >> selected window small, it will neither remove nor change it.
>  >
>  > Never-ever?
> 
> Never-ever.  Fdelete_window_internal, Fdelete_other_windows_internal and
> Fset_window_configuration are the only functions allowed to delete
> windows.

Not even due to some Lisp hook run directly or indirectly when the
frame is resized?

If this can never happen, we should replace the test with an
assertion, and wait for it to fire if we are missing something.

> run_window_change_functions could delete the selected window
> so we probably should do the w == sw check after that now.

Yes, I think so.  Patches welcome.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >> In either case, the more I look into this, the more things confuse me.
 >> For example, why does
 >>
 >> 	  if (!must_finish)
 >> 	    {
 >> 	      do_pending_window_change (true);
 >> 	      /* If selected_window changed, redisplay again.  */
 >> 	      if (WINDOWP (selected_window)
 >> 		  && (w = XWINDOW (selected_window)) != sw)
 >> 		goto retry;
 >>
 >> not check for windows_or_buffers_changed too just as we do after the
 >> third do_pending_window_change call?
 >
 > Because going to 'retry' will eventually make that check again.  Or
 > maybe I don't understand what exactly are you asking here?

The check above doesn't care about windows_or_buffers_changed.  The last
one in redisplay_internal does:

   /* Change frame size now if a change is pending.  */
   do_pending_window_change (true);

   /* If we just did a pending size change, or have additional
      visible frames, or selected_window changed, redisplay again.  */
   if ((windows_or_buffers_changed && !pending)
       || (WINDOWP (selected_window)
	  && (w = XWINDOW (selected_window)) != sw))
     goto retry;

So if in the (!must_finish) guarded check windows_or_buffers_changed was
set but the selected window remained unchanged, we don't go to retry.

 >> But then I don't understand why we
 >> check for windows_or_buffers_changed at all.  adjust_frame_size doesn't
 >> set that IIUC but it does garbage the frame - why don't we check that in
 >> redisplay_internal?
 >
 > Sorry, I don't understand the question.  We _are_ talking about
 > redisplay_internal, right? and redisplay_internal does check
 > windows_or_buffers_changed, right? so what do you mean by "why don't
 > we check that in redisplay_internal"? and what is "that" in this case?

I meant to ask why we don't check the f->garbaged flag of the frame
instead of windows_or_buffers_changed.  do_pending_window_change to my
knowledge does not set windows_or_buffers_changed but sets the garbaged
flag.

 >> Never-ever.  Fdelete_window_internal, Fdelete_other_windows_internal and
 >> Fset_window_configuration are the only functions allowed to delete
 >> windows.
 >
 > Not even due to some Lisp hook run directly or indirectly when the
 > frame is resized?

run_window_scroll_functions could do it later on, but that is run by
redisplay itself.

 > If this can never happen, we should replace the test with an
 > assertion, and wait for it to fire if we are missing something.

I'll try that here.

martin

bug#46827: Broken initial size of GTK3 frame

[Eli Zaretskii]

> Cc: stephen.berman@gmx.net, rpluim@gmail.com, 46827@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 3 Mar 2021 10:40:04 +0100
> 
>  >> 	  if (!must_finish)
>  >> 	    {
>  >> 	      do_pending_window_change (true);
>  >> 	      /* If selected_window changed, redisplay again.  */
>  >> 	      if (WINDOWP (selected_window)
>  >> 		  && (w = XWINDOW (selected_window)) != sw)
>  >> 		goto retry;
>  >>
>  >> not check for windows_or_buffers_changed too just as we do after the
>  >> third do_pending_window_change call?
>  >
>  > Because going to 'retry' will eventually make that check again.  Or
>  > maybe I don't understand what exactly are you asking here?
> 
> The check above doesn't care about windows_or_buffers_changed.  The last
> one in redisplay_internal does:
> 
>    /* Change frame size now if a change is pending.  */
>    do_pending_window_change (true);
> 
>    /* If we just did a pending size change, or have additional
>       visible frames, or selected_window changed, redisplay again.  */
>    if ((windows_or_buffers_changed && !pending)
>        || (WINDOWP (selected_window)
> 	  && (w = XWINDOW (selected_window)) != sw))
>      goto retry;
> 
> So if in the (!must_finish) guarded check windows_or_buffers_changed was
> set but the selected window remained unchanged, we don't go to retry.

I still don't see the problem, because that last check you show above
will catch that, right?

>  >> But then I don't understand why we
>  >> check for windows_or_buffers_changed at all.  adjust_frame_size doesn't
>  >> set that IIUC but it does garbage the frame - why don't we check that in
>  >> redisplay_internal?
>  >
>  > Sorry, I don't understand the question.  We _are_ talking about
>  > redisplay_internal, right? and redisplay_internal does check
>  > windows_or_buffers_changed, right? so what do you mean by "why don't
>  > we check that in redisplay_internal"? and what is "that" in this case?
> 
> I meant to ask why we don't check the f->garbaged flag of the frame
> instead of windows_or_buffers_changed.  do_pending_window_change to my
> knowledge does not set windows_or_buffers_changed but sets the garbaged
> flag.

SET_FRAME_GARBAGED also causes windows_or_buffers_changed to be set.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > I still don't see the problem, because that last check you show above
 > will catch that, right?

You mean that if windows_or_buffers_changed, we handle that in the last
check and all the former check has to do is to assure that the selected
window is right?  Then why do we call do_pending_window_change at all in
the "second" case.  Because we might go to end_of_redisplay right from
there?  But then the third check won't catch it.  I'm clearly confused.

 > SET_FRAME_GARBAGED also causes windows_or_buffers_changed to be set.

Via 'redisplay_other_windows', I see.

martin

bug#46827: Broken initial size of GTK3 frame

[Stephen Berman]

(I saw your post with the do_pending_window_change patch just as I was
about to send the following, which therefore may now be irrelevant.  I
haven't tried the patch yet.)

On Tue, 2 Mar 2021 09:24:38 +0100 martin rudalics <rudalics@gmx.at> wrote:

>>> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
>>> present, I do sometimes see the frame issue you reported, which
>>> suggests itʼs a timing issue somewhere.
>>
>> Evidence in favor of that suggestion may be the following observations:
>> I can reliably reproduce the problematic display (on xfwm4-4.14.1 with
>> GTK+ 3.24.17) with the first invocation below, but not with the second
>> invocation:
>
> Why is this evidence in favor of the above suggestion?

Since sleep-for pauses without redisplay and sit-for pauses after
redisplay, I thought that points to a possible timing issue.

>> $ emacs-master -Q --eval "(customize-set-variable 'default-frame-alist
>> '((cursor-color . \"red3\") (width . 80) (height . 32)))"
>>
>> $ emacs-master -Q --eval "(progn (sleep-for .1) (customize-set-variable
>> 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height
>> . 32))))"
>>
>> Yet I can also reproduce the display problem with the following
>> invocation:
>>
>> $ emacs-master -Q --eval "(progn (sit-for .1) (customize-set-variable
>> 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height
>> . 32))))"
>
> Both `sleep-for' and `sit-for' with an abismal small argument work here,
> 0 does not.  So the problem still seems that redisplay misses a pending
> window change.  I have no idea why `sleep-for' and `sit-for' behave
> differently for you though.

I also see the problem consistently with (sit-for .01) and (sit-for
.001) but consistently don't see it with (sit-for .00001) and (sit-for
.000001).  With (sit-for .0001) the problems has appeared on some
invocations and not on others.  With sleep-for I haven't seen the
problem with .1, .01, .001 or .0001, but with .00001 and .000001 I have
seen it on some invocations but not on others.  With both (sit-for 0)
and (sleep-for 0) I've seen the problem on some invocations and not seen
it on others.  These observations also suggest to me a timing issue, but
my understanding of such things is very likely too poor to justify and
inferences.

Steve Berman

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >>>> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
 >>>> present, I do sometimes see the frame issue you reported, which
 >>>> suggests itʼs a timing issue somewhere.
 >>>
 >>> Evidence in favor of that suggestion may be the following observations:
 >>> I can reliably reproduce the problematic display (on xfwm4-4.14.1 with
 >>> GTK+ 3.24.17) with the first invocation below, but not with the second
 >>> invocation:
 >>
 >> Why is this evidence in favor of the above suggestion?
 >
 > Since sleep-for pauses without redisplay and sit-for pauses after
 > redisplay, I thought that points to a possible timing issue.

I meant the "no dump file present issue".  How is that related to timing
issues?

 >> Both `sleep-for' and `sit-for' with an abismal small argument work here,
 >> 0 does not.  So the problem still seems that redisplay misses a pending
 >> window change.  I have no idea why `sleep-for' and `sit-for' behave
 >> differently for you though.

I forgot to mention that both, `sleep-for' and `sit-for' with arbitrary
non-zero arguments give a good frame here.  Only with a zero argument,
they give a bad frame.

 > I also see the problem consistently with (sit-for .01) and (sit-for
 > .001) but consistently don't see it with (sit-for .00001) and (sit-for
 > .000001).  With (sit-for .0001) the problems has appeared on some
 > invocations and not on others.  With sleep-for I haven't seen the
 > problem with .1, .01, .001 or .0001, but with .00001 and .000001 I have
 > seen it on some invocations but not on others.  With both (sit-for 0)
 > and (sleep-for 0) I've seen the problem on some invocations and not seen
 > it on others.  These observations also suggest to me a timing issue, but
 > my understanding of such things is very likely too poor to justify and
 > inferences.

These observations quite substantially contradict mine.  Why would the
bad frame appear with `sit-for' and _larger_ timeouts?  I'd have
expected the contrary.  OTOH the `sleep-for' behavior sounds reasonable.

martin

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > 30. A lucid build gives me 31, so itʼs no better. (all emacs-27)

Here only GTK3 builds are affected.  Back then it took me months to get
these right.  So the values you report above are quite annoying.  Maybe
someone else could try ...

 > <wild stab in the dark> What happens if you disable the code that
 > displays text labels in the tool bar:

I thought about that too but it doesn't help.

martin

bug#46827: Broken initial size of GTK3 frame

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 1 Mar 2021 09:31:20 +0100
> 
> It turns out that the "something else" is just that
> 
>               /* Querying further backends can be very slow, so we only do
>                  it if the user has explicitly requested it (Bug#43177).  */
>               if (query_all_font_backends == false)
>                 break;
> 
> The attached patch reverting 58430f29968a5661caff630d20dbbe7c864fe08d
> and removing the entity above fixes the bug on master.

Thanks, but removing the zero_vector entity is a non-starter.  We paid
dearly for that change, so I don't want to get that problem back
again.

The other change is also quite important.

We need to find a better way of fixing this problem.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >> The attached patch reverting 58430f29968a5661caff630d20dbbe7c864fe08d
 >> and removing the entity above fixes the bug on master.
 >
 > Thanks, but removing the zero_vector entity is a non-starter.  We paid
 > dearly for that change, so I don't want to get that problem back
 > again.
 >
 > The other change is also quite important.
 >
 > We need to find a better way of fixing this problem.

Agreed to both.  I'd just have to understand first how the above can
and do affect redisplay.

martin

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

tags 46827 fixed
close 46827 28.1
quit

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

As Robert and Stephen have independently observed, this is a Heisenbug.
It's due to to the fact that WM notifications about new frame sizes may
be processed earlier or later.  I tried to fix that behavior in commit
a190b4cfd8b6f42a91678ac7292e1cceccd168e7 by having adjust_frame_size
pick up such notifications on the fly and am closing this bug.

Thanks, martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

> It's due to to the fact that WM notifications about new frame sizes may
> be processed earlier or later.  I tried to fix that behavior in commit
> a190b4cfd8b6f42a91678ac7292e1cceccd168e7 by having adjust_frame_size
> pick up such notifications on the fly and am closing this bug.

Unfortunately, this commit caused a regression: now there is distracting
blinking of the frame that looks like the visual effect of visible-bell
when it flashes the frame to represent a bell.

This problem can be reproduced only in Gnus.  With such configuration:

  (push '("\\`\\*Summary .*\\*\\'" .
          (display-buffer-in-tab
           (tab-name . "*Summary*")))
        display-buffer-alist)

opening a Gnus group in a new tab flashes the whole frame where empty space
instead of the frame content is visible for a short time.

This problem can't be reproduced with just creating a new tab,
it only manifests in Gnus, maybe something in gnus-summary-read-group-1
with gnus-configure-windows forces frame redisplay or something like this.

This problem doesn't exist without recent changes in a190b4cfd8.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >> It's due to to the fact that WM notifications about new frame sizes may
 >> be processed earlier or later.  I tried to fix that behavior in commit
 >> a190b4cfd8b6f42a91678ac7292e1cceccd168e7 by having adjust_frame_size
 >> pick up such notifications on the fly and am closing this bug.
 >
 > Unfortunately, this commit caused a regression: now there is distracting
 > blinking of the frame that looks like the visual effect of visible-bell
 > when it flashes the frame to represent a bell.
 >
 > This problem can be reproduced only in Gnus.  With such configuration:
 >
 >    (push '("\\`\\*Summary .*\\*\\'" .
 >            (display-buffer-in-tab
 >             (tab-name . "*Summary*")))
 >          display-buffer-alist)
 >
 > opening a Gnus group in a new tab flashes the whole frame where empty space
 > instead of the frame content is visible for a short time.
 >
 > This problem can't be reproduced with just creating a new tab,
 > it only manifests in Gnus, maybe something in gnus-summary-read-group-1
 > with gnus-configure-windows forces frame redisplay or something like this.
 >
 > This problem doesn't exist without recent changes in a190b4cfd8.

Please try to provide some sort of recipe to reproduce this.  Ideally
without Gnus because I never used it.  Also, I've never seen a frame
"flash".  Is that a new frame?  Is there anything broken in the frame
after the flash?

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

>> opening a Gnus group in a new tab flashes the whole frame where empty space
>> instead of the frame content is visible for a short time.
>>
>> This problem can't be reproduced with just creating a new tab,
>> it only manifests in Gnus, maybe something in gnus-summary-read-group-1
>> with gnus-configure-windows forces frame redisplay or something like this.
>>
>> This problem doesn't exist without recent changes in a190b4cfd8.
>
> Please try to provide some sort of recipe to reproduce this.  Ideally
> without Gnus because I never used it.  Also, I've never seen a frame

Sorry, not easy to distill many different things Gnus does to massage windows
into a simpler test case.

> "flash".  Is that a new frame?  Is there anything broken in the frame
> after the flash?

It's in the same frame, and nothing is broken after the flash.
The visual effect is that after creating a new tab, everything
is erased on the frame including tab bars and the mode line
for a short time, and then redrawn back.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >> Please try to provide some sort of recipe to reproduce this.  Ideally
 >> without Gnus because I never used it.  Also, I've never seen a frame
 >
 > Sorry, not easy to distill many different things Gnus does to massage windows
 > into a simpler test case.

I understand.  But since nobody else has reported a similar issue till
now, I strongly suspect that `display-buffer-in-tab' is triggering it.

 >> "flash".  Is that a new frame?  Is there anything broken in the frame
 >> after the flash?
 >
 > It's in the same frame, and nothing is broken after the flash.
 > The visual effect is that after creating a new tab, everything
 > is erased on the frame including tab bars and the mode line
 > for a short time, and then redrawn back.

If this is GTK can you try with `x-wait-for-event-timeout' set to say 10
and tell whether that "flash" then takes ten seconds?  Here I've never
seen that "everything is erased on the frame" - usually some garbage
from elsewhere remains ...

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

> If this is GTK can you try with `x-wait-for-event-timeout' set to say 10
> and tell whether that "flash" then takes ten seconds?  Here I've never
> seen that "everything is erased on the frame" - usually some garbage
> from elsewhere remains ...

Changing x-wait-for-event-timeout from 0.1 to 10 has no effect
on x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0.

I tried to add a message at the top of window--display-buffer,
and there are no more flashes when a message is displayed.

Then tried to add `(sit-for 0)' to window--display-buffer,
and no flashes anymore too.  So it seems this is a Heisenbug.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >> If this is GTK can you try with `x-wait-for-event-timeout' set to say 10
 >> and tell whether that "flash" then takes ten seconds?  Here I've never
 >> seen that "everything is erased on the frame" - usually some garbage
 >> from elsewhere remains ...
 >
 > Changing x-wait-for-event-timeout from 0.1 to 10 has no effect
 > on x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0.
 >
 > I tried to add a message at the top of window--display-buffer,
 > and there are no more flashes when a message is displayed.
 >
 > Then tried to add `(sit-for 0)' to window--display-buffer,
 > and no flashes anymore too.  So it seems this is a Heisenbug.

Is the behavior in any way frame related - do you resize your frame, add
a tab bar, resize the tab bar?  I did not touch the Emacs window code.

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

>> I tried to add a message at the top of window--display-buffer,
>> and there are no more flashes when a message is displayed.
>>
>> Then tried to add `(sit-for 0)' to window--display-buffer,
>> and no flashes anymore too.  So it seems this is a Heisenbug.
>
> Is the behavior in any way frame related - do you resize your frame, add
> a tab bar, resize the tab bar?  I did not touch the Emacs window code.

No frame resizes, the frame always stays maximized and undecorated,
and the tab bar is not resized.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > No frame resizes, the frame always stays maximized and undecorated,
 > and the tab bar is not resized.

Let's check whether the frame code is affected.  With you original
scenario and also with the two scenarios where you successfully suppress
the flashes do

1: Eval (setq frame-size-history '(100))

2: Run the Gnus setup

3: Eval (progn (frame--size-history) (pop-to-buffer "*frame-size-history*"))

all in one and the same frame.  Then post the contents of the buffer
*frame-size-history* for each of them.

Thanks, martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

> Let's check whether the frame code is affected.  With you original
> scenario and also with the two scenarios where you successfully suppress
> the flashes do

Actually, now there is only one successful scenario: it doesn't flash
with sit-for, but still flashes with a message.

> 1: Eval (setq frame-size-history '(100))
>
> 2: Run the Gnus setup
>
> 3: Eval (progn (frame--size-history) (pop-to-buffer "*frame-size-history*"))
>
> all in one and the same frame.  Then post the contents of the buffer
> *frame-size-history* for each of them.

1. when the frame flashes:

Frame size history of #<frame  *Minibuf-1* 0x55555935ffb0>
tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=80x85 IH IV
x_make_frame_visible
set_window_configuration (4), MS=80x85 IH IV

2. when no flash after adding sit-for in window--display-buffer:

Frame size history of #<frame  *Minibuf-1* 0x55555935ffb0>
tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=32x51 IH IV
x_make_frame_visible
set_window_configuration (4), MS=80x85 IH IV

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > Actually, now there is only one successful scenario: it doesn't flash
 > with sit-for, but still flashes with a message.

Does "now" mean after my most recent commit?

 >> 1: Eval (setq frame-size-history '(100))
 >>
 >> 2: Run the Gnus setup
 >>
 >> 3: Eval (progn (frame--size-history) (pop-to-buffer "*frame-size-history*"))
 >>
 >> all in one and the same frame.  Then post the contents of the buffer
 >> *frame-size-history* for each of them.
 >
 > 1. when the frame flashes:
 >
 > Frame size history of #<frame  *Minibuf-1* 0x55555935ffb0>
 > tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
 > tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=80x85 IH IV
 > x_make_frame_visible
 > set_window_configuration (4), MS=80x85 IH IV
 >
 > 2. when no flash after adding sit-for in window--display-buffer:
 >
 > Frame size history of #<frame  *Minibuf-1* 0x55555935ffb0>
 > tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
 > tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=32x51 IH IV
 > x_make_frame_visible
 > set_window_configuration (4), MS=80x85 IH IV

Didn't you earlier say that all this happens in a maximized frame?  The
sizes above seem to contradict that.  In either case, someone requests
to enlarge and shrink the tab bar by two pixels which contradicts your
earlier "and the tab bar is not resized".  So who wants to do that to
the tab bar and why?  And who wants to set the window configuration here
and why?

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

>> Actually, now there is only one successful scenario: it doesn't flash
>> with sit-for, but still flashes with a message.
>
> Does "now" mean after my most recent commit?

I don't know whether it affected since anyway sit-for can be used for
workaround as a test without flash.

> Didn't you earlier say that all this happens in a maximized frame?  The
> sizes above seem to contradict that.

For testing, I tried in an unmaximized frame, but the problem is the same.

> In either case, someone requests to enlarge and shrink the tab bar by
> two pixels which contradicts your earlier "and the tab bar is not
> resized".

There are no visible resizes.

> So who wants to do that to the tab bar and why?

I don't know who wants to resize by two pixels.

> And who wants to set the window configuration here and why?

I added a breakpoint in set-window-configuration, and it's called from
tab-bar-select-tab in Gnus.

In total there are 4 tab switches with 4 calls of set-window-configuration.
But after removing gnus-remove-some-windows, when set-window-configuration
is not called at all, there are still the same flashes.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

Please try it and tell me whether the frame size history (hoperemains empty
now.

 >  > 1. when the frame flashes:
 >  >
 >  > Frame size history of #<frame  *Minibuf-1* 0x55555935ffb0>
 >  > tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
 >  > tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=80x85 IH IV
 >  > x_make_frame_visible
 >  > set_window_configuration (4), MS=80x85 IH IV
 >  >
 >  > 2. when no flash after adding sit-for in window--display-buffer:
 >  >
 >  > Frame size history of #<frame  *Minibuf-1* 0x55555935ffb0>
 >  > tab-bar-lines (3), TS=640x610~>640x612, TC=80x35~>80x36, IS=656x610~>656x612, MS=32x51 IH IV
 >  > tab-bar-lines (3), TS=640x612~>640x610, TC=80x36~>80x35, IS=656x612~>656x610, MS=32x51 IH IV
 >  > x_make_frame_visible
 >  > set_window_configuration (4), MS=80x85 IH IV
 >
 > Didn't you earlier say that all this happens in a maximized frame?  The
 > sizes above seem to contradict that.  In either case, someone requests
 > to enlarge and shrink the tab bar by two pixels which contradicts your
 > earlier "and the tab bar is not resized".  So who wants to do that to
 > the tab bar and why?  And who wants to set the window configuration here
 > and why?

What apparently happens is the following: x_set_tab_bar_lines (why?)
gets called all the time with a VALUE of 1 and translates that to
FRAME_LINE_HEIGHT (f) when calling x_change_tab_bar_height.  So the
latter sets FRAME_TAB_BAR_HEIGHT (f) to FRAME_LINE_HEIGHT (f) which is
two pixels less than the height needed to display the tab bar.  This
means we enlarge and move upwards the root window by two pixels and
later shrink and move it down when redisplay has calculated the new
size.

The attached patch tries to fix that.  Note that a simple

nlines != olines

is not sufficient since the tab bar occupies 2 lines while VALUE is 1.

Maybe we should do a similar thing for the tool and/or menu bars (but I
recall that some builds do process a VALUE > 1 specially for them).

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xfns.c.diff --]
[-- Type: text/x-patch; name="xfns.c.diff", Size: 738 bytes --]

diff --git a/src/xfns.c b/src/xfns.c
index 2c95065d3e..c6a128ef51 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -1615,6 +1615,7 @@ x_set_menu_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
 static void
 x_set_tab_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
 {
+  int olines = FRAME_TAB_BAR_LINES (f);
   int nlines;

   /* Treat tab bars like menu bars.  */
@@ -1627,7 +1628,8 @@ x_set_tab_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
   else
     nlines = 0;

-  x_change_tab_bar_height (f, nlines * FRAME_LINE_HEIGHT (f));
+  if (nlines != olines && (olines == 0 || nlines == 0))
+    x_change_tab_bar_height (f, nlines * FRAME_LINE_HEIGHT (f));
 }

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

> Please try it and tell me whether the frame size history (hoperemains empty
> now.

Tried it, and no flashes anymore, thanks!

Here is the frame size history:

  Frame size history of #<frame  *Minibuf-1* 0x55555f0f7a58>
  x_make_frame_visible
  set_window_configuration (4), MS=80x85 IH IV

> What apparently happens is the following: x_set_tab_bar_lines (why?)
> gets called all the time with a VALUE of 1 and translates that to
> FRAME_LINE_HEIGHT (f) when calling x_change_tab_bar_height.  So the
> latter sets FRAME_TAB_BAR_HEIGHT (f) to FRAME_LINE_HEIGHT (f) which is
> two pixels less than the height needed to display the tab bar.  This
> means we enlarge and move upwards the root window by two pixels and
> later shrink and move it down when redisplay has calculated the new
> size.
>
> The attached patch tries to fix that.  Note that a simple
>
> nlines != olines
>
> is not sufficient since the tab bar occupies 2 lines while VALUE is 1.
>
> Maybe we should do a similar thing for the tool and/or menu bars (but I
> recall that some builds do process a VALUE > 1 specially for them).

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > Tried it, and no flashes anymore, thanks!

Fine.

martin

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >  > Tried it, and no flashes anymore, thanks!

Pushed now.  But I think that tab-bar.el should really refrain from
updating the tab-bar-lines parameter from one positive value to another
(I suppose `tab-bar--update-tab-bar-lines' does that).

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

>>  > Tried it, and no flashes anymore, thanks!
>
> Pushed now.  But I think that tab-bar.el should really refrain from
> updating the tab-bar-lines parameter from one positive value to another
> (I suppose `tab-bar--update-tab-bar-lines' does that).

It seems tab-bar.el already updates only between 0 and 1.

But even updating between 0 and 1 caused the problems.
We have bug#46557 created from https://debbugs.gnu.org/46299#119
I tried the test case from this bug report, and it doesn't fail anymore.
Do you think your patch fixed this old bug?

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > It seems tab-bar.el already updates only between 0 and 1.

That's not what I've seen.

 > But even updating between 0 and 1 caused the problems.
 > We have bug#46557 created from https://debbugs.gnu.org/46299#119
 > I tried the test case from this bug report, and it doesn't fail anymore.
 > Do you think your patch fixed this old bug?

You mean an init file with

(set-frame-parameter nil 'tab-bar-lines 0)
(set-frame-parameter nil 'tab-bar-lines 1)
(set-frame-parameter nil 'tab-bar-lines 0)

and doing C-x t 2?  I have never seen any problems with that so I can't
tell.  But it's my experience that whatever we do to our frames, it's
hard to break the external menu bar.

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

>> It seems tab-bar.el already updates only between 0 and 1.
>
> That's not what I've seen.

There are no other values used in source code of tab-bar.el.
But maybe sometimes the value of tab-bar-lines
becomes more than 1?

>> But even updating between 0 and 1 caused the problems.
>> We have bug#46557 created from https://debbugs.gnu.org/46299#119
>> I tried the test case from this bug report, and it doesn't fail anymore.
>> Do you think your patch fixed this old bug?
>
> You mean an init file with
>
> (set-frame-parameter nil 'tab-bar-lines 0)
> (set-frame-parameter nil 'tab-bar-lines 1)
> (set-frame-parameter nil 'tab-bar-lines 0)
>
> and doing C-x t 2?  I have never seen any problems with that so I can't
> tell.  But it's my experience that whatever we do to our frames, it's
> hard to break the external menu bar.

The bug was reproducible only on GNU/Linux, not on MS-Windows.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >>> It seems tab-bar.el already updates only between 0 and 1.
 >>
 >> That's not what I've seen.
 >
 > There are no other values used in source code of tab-bar.el.
 > But maybe sometimes the value of tab-bar-lines
 > becomes more than 1?

It's 2 after the tab bar has been produced for the first time by the
display code.  And that is what's been causing trouble for you.  The
value was oscillating between 1 and 2.

 >> But it's my experience that whatever we do to our frames, it's
 >> hard to break the external menu bar.
 >
 > The bug was reproducible only on GNU/Linux, not on MS-Windows.

I've never been able to produce a "broken menu bar" on any build.

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

>>>> It seems tab-bar.el already updates only between 0 and 1.
>>>
>>> That's not what I've seen.
>>
>> There are no other values used in source code of tab-bar.el.
>> But maybe sometimes the value of tab-bar-lines
>> becomes more than 1?
>
> It's 2 after the tab bar has been produced for the first time by the
> display code.  And that is what's been causing trouble for you.  The
> value was oscillating between 1 and 2.

Very strange indeed, I can't find the constant 2 in the source code.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >>> But maybe sometimes the value of tab-bar-lines
 >>> becomes more than 1?
 >>
 >> It's 2 after the tab bar has been produced for the first time by the
 >> display code.  And that is what's been causing trouble for you.  The
 >> value was oscillating between 1 and 2.
 >
 > Very strange indeed, I can't find the constant 2 in the source code.

Because for X it's done in x_change_tab_bar_height as (I suppose you
wrote that):


x_change_tab_bar_height (struct frame *f, int height)
{
   int unit = FRAME_LINE_HEIGHT (f);
   int old_height = FRAME_TAB_BAR_HEIGHT (f);
   int lines = (height + unit - 1) / unit;
   Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);

   /* Make sure we redisplay all windows in this frame.  */
   fset_redisplay (f);

   /* Recalculate tab bar and frame text sizes.  */
   FRAME_TAB_BAR_HEIGHT (f) = height;
   FRAME_TAB_BAR_LINES (f) = lines;
   store_frame_param (f, Qtab_bar_lines, make_fixnum (lines));


If you call this with a HEIGHT that is larger than FRAME_LINE_HEIGHT you
already get a `tab-bar-lines' parameter that is larger than 1.  With a
very small FRAME_LINE_HEIGHT and/or a very tall tab bar you may get more
than 2 lines.

This is an idiosyncrasy of our "live in a graphic world but think in
terms of a TTY" philosophy.  The parameter should be a boolean and have
been called something like 'tab_bar_p' but there's no chance to change
that any more.

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

> x_change_tab_bar_height (struct frame *f, int height)
> {
>   int unit = FRAME_LINE_HEIGHT (f);
>   int old_height = FRAME_TAB_BAR_HEIGHT (f);
>   int lines = (height + unit - 1) / unit;
>   Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);
>
>   /* Make sure we redisplay all windows in this frame.  */
>   fset_redisplay (f);
>
>   /* Recalculate tab bar and frame text sizes.  */
>   FRAME_TAB_BAR_HEIGHT (f) = height;
>   FRAME_TAB_BAR_LINES (f) = lines;
>   store_frame_param (f, Qtab_bar_lines, make_fixnum (lines));
>
> If you call this with a HEIGHT that is larger than FRAME_LINE_HEIGHT you
> already get a `tab-bar-lines' parameter that is larger than 1.  With a
> very small FRAME_LINE_HEIGHT and/or a very tall tab bar you may get more
> than 2 lines.

Indeed, initially:

  lines = (17 + 17 - 1) / 17 = 1

but later:

  lines = (19 + 17 - 1) / 17 = 2

> This is an idiosyncrasy of our "live in a graphic world but think in
> terms of a TTY" philosophy.  The parameter should be a boolean and have
> been called something like 'tab_bar_p' but there's no chance to change
> that any more.

But what if the tab bar is so long that it wraps and really occupies 2 lines
on a GUI?

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > But what if the tab bar is so long that it wraps and really occupies 2 lines
 > on a GUI?

What are "2 lines on a GUI"?  If you mean "logical lines", only the
display engine - the entity responsible for detecting whether a tab bar
line must be wrapped - can tell.  We could easily set the value of the
'tab-bar-lines' parameter to that - it would make more sense than what
we have now.  Currently, (frame-parameter nil 'tab-bar-lines) yields "3"
when I have one logical tab bar line that wraps when I make the frame
narrow enough.

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

>> But what if the tab bar is so long that it wraps and really occupies 2 lines
>> on a GUI?
>
> What are "2 lines on a GUI"?  If you mean "logical lines", only the

Yes, wrapped logical lines.

> display engine - the entity responsible for detecting whether a tab bar
> line must be wrapped - can tell.  We could easily set the value of the
> 'tab-bar-lines' parameter to that - it would make more sense than what
> we have now.  Currently, (frame-parameter nil 'tab-bar-lines) yields "3"
> when I have one logical tab bar line that wraps when I make the frame
> narrow enough.

I see the same.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >> display engine - the entity responsible for detecting whether a tab bar
 >> line must be wrapped - can tell.  We could easily set the value of the
 >> 'tab-bar-lines' parameter to that - it would make more sense than what
 >> we have now.  Currently, (frame-parameter nil 'tab-bar-lines) yields "3"
 >> when I have one logical tab bar line that wraps when I make the frame
 >> narrow enough.
 >
 > I see the same.

Do we want to change it?  Then we'd probably have to change the
semantics of this for tool bar and menu bar lines too.  Note: In
practice we care only about zero or not zero here.

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

>>> display engine - the entity responsible for detecting whether a tab bar
>>> line must be wrapped - can tell.  We could easily set the value of the
>>> 'tab-bar-lines' parameter to that - it would make more sense than what
>>> we have now.  Currently, (frame-parameter nil 'tab-bar-lines) yields "3"
>>> when I have one logical tab bar line that wraps when I make the frame
>>> narrow enough.
>>
>> I see the same.
>
> Do we want to change it?  Then we'd probably have to change the
> semantics of this for tool bar and menu bar lines too.

Isn't this a bug that the tool bar and menu bar incorrectly calculate lines?

> Note: In practice we care only about zero or not zero here.

It could also help to detect the situation when lines are wrapped.

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 > Isn't this a bug that the tool bar and menu bar incorrectly calculate lines?

The lines are calculated correctly by rounding up when we divide the
object's pixel height by the default character height of the frame.  But
that calculated value is useless on a GUI.

 >> Note: In practice we care only about zero or not zero here.
 >
 > It could also help to detect the situation when lines are wrapped.

For internal objects (like the Lucid or Windows tool bar or your tab
bars) only the display engine can reliable do that.  For external
objects (like the Motif or Windows menu bars) detecting wrapping is
unreliable anyway.

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

>> Isn't this a bug that the tool bar and menu bar incorrectly calculate lines?
>
> The lines are calculated correctly by rounding up when we divide the
> object's pixel height by the default character height of the frame.  But
> that calculated value is useless on a GUI.

Accoring to window-total-height, the currently used rounding
in x_change_tab_bar_height corresponds to 'ceiling':

      return make_fixnum (EQ (round, Qceiling)
			  ? ((w->pixel_height + unit - 1) /unit)

On a TTY where the frame line height is 1, this gives the correct result.
But not on a GUI where the frame line height is measured in pixels.

When the argument 'round' of window-total-height is 'floor',
it uses the formula without subtracting 1 that works on a GUI too:

			  : (w->pixel_height / unit));

This patch fixes this in x_change_tab_bar_height.  Do you think the same
fix should be applied to x_change_tool_bar_height as well?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: x_change_tab_bar_height.patch --]
[-- Type: text/x-diff, Size: 466 bytes --]

diff --git a/src/xfns.c b/src/xfns.c
index e46616e6d6..82d22cc5f8 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -1640,7 +1640,7 @@ x_change_tab_bar_height (struct frame *f, int height)
 {
   int unit = FRAME_LINE_HEIGHT (f);
   int old_height = FRAME_TAB_BAR_HEIGHT (f);
-  int lines = (height + unit - 1) / unit;
+  int lines = height / unit;
   Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);
 
   /* Make sure we redisplay all windows in this frame.  */

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >> The lines are calculated correctly by rounding up when we divide the
 >> object's pixel height by the default character height of the frame.  But
 >> that calculated value is useless on a GUI.
 >
 > Accoring to window-total-height, the currently used rounding
 > in x_change_tab_bar_height corresponds to 'ceiling':
 >
 >        return make_fixnum (EQ (round, Qceiling)
 > 			  ? ((w->pixel_height + unit - 1) /unit)
 >
 > On a TTY where the frame line height is 1, this gives the correct result.
 > But not on a GUI where the frame line height is measured in pixels.
 >
 > When the argument 'round' of window-total-height is 'floor',
 > it uses the formula without subtracting 1 that works on a GUI too:
 >
 > 			  : (w->pixel_height / unit));
 >
 > This patch fixes this in x_change_tab_bar_height.  Do you think the same
 > fix should be applied to x_change_tool_bar_height as well?

What does your patch fix?  With a sufficiently small default font this
will still return a value > 1.  In either case, the height of the
frame's inner rectangle plus those of internal tab, tool and menu bar
should equal the height of the native rectangle in lines.  Did you check
that?

In my experience, there's no way to make column/line based variables and
functions always DTRT on a GUI.  Code should avoid them.

martin

bug#46827: Broken initial size of GTK3 frame

[Juri Linkov]

>> Accoring to window-total-height, the currently used rounding
>> in x_change_tab_bar_height corresponds to 'ceiling':
>>
>>        return make_fixnum (EQ (round, Qceiling)
>> 			  ? ((w->pixel_height + unit - 1) /unit)
>>
>> On a TTY where the frame line height is 1, this gives the correct result.
>> But not on a GUI where the frame line height is measured in pixels.
>>
>> When the argument 'round' of window-total-height is 'floor',
>> it uses the formula without subtracting 1 that works on a GUI too:
>>
>> 			  : (w->pixel_height / unit));
>>
>> This patch fixes this in x_change_tab_bar_height.  Do you think the same
>> fix should be applied to x_change_tool_bar_height as well?
>
> What does your patch fix?

There are no more oscillations between 1 and 2 on a GUI.

> With a sufficiently small default font this will still return a value > 1.

I use very small font, and the value is always 1.  Only when the tab bar
is wrapped, the value becomes 2.

> In either case, the height of the frame's inner rectangle plus those
> of internal tab, tool and menu bar should equal the height of the
> native rectangle in lines.  Did you check that?

I don't know how to check this.

> In my experience, there's no way to make column/line based variables and
> functions always DTRT on a GUI.  Code should avoid them.

Is it possible to avoid this when tab-bar-lines are calculated?

bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

 >> What does your patch fix?
 >
 > There are no more oscillations between 1 and 2 on a GUI.
 >
 >> With a sufficiently small default font this will still return a value > 1.
 >
 > I use very small font, and the value is always 1.  Only when the tab bar
 > is wrapped, the value becomes 2.

I merely referred to the tool bar whose height (especially on KDE) often
exceeds that of the default font by more than 2.  For the tab bar, try
to scale the tab-bar face by a factor of 2.0 or increase the height of
the `variable-pitch' face.

 >> In either case, the height of the frame's inner rectangle plus those
 >> of internal tab, tool and menu bar should equal the height of the
 >> native rectangle in lines.  Did you check that?
 >
 > I don't know how to check this.

I doubt that we do it correctly now.  There's a check that tries to make
window sizes in lines and columns sum up correctly but there's no such
check for the frame decorations IIRC.

 >> In my experience, there's no way to make column/line based variables and
 >> functions always DTRT on a GUI.  Code should avoid them.
 >
 > Is it possible to avoid this when tab-bar-lines are calculated?

IIUC we have two ways to calculate tab-bar-lines in a logically correct
way: Have the display engine do it explicitly whenever it detects that a
tab-bar line is wrapped or implicitly by inspecting the glyph matrix
after the display engine is done with the tab bar.  A similar approach
can be used for the tool bar on Lucid/Motif/Windows and both tool and
menu bar on builds without toolkit support.

martin