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