Subject: Re: bug#46827: Broken initial size of GTK3 frame

From: martin rudalics <[email-masked]>
Date: Tue, 2 Mar 2021 09:24:38 +0100

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