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

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46827 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>
Subject: bug#46827: Broken initial size of GTK3 frame
Date: Tue, 02 Mar 2021 10:17:17 +0100

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

Previous Next

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