[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46827: Broken initial size of GTK3 frame
From: |
Stephen Berman |
Subject: |
bug#46827: Broken initial size of GTK3 frame |
Date: |
Tue, 02 Mar 2021 10:17:17 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
(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, (continued)
- bug#46827: Broken initial size of GTK3 frame, martin rudalics, 2021/03/02
- bug#46827: Broken initial size of GTK3 frame, Robert Pluim, 2021/03/02
- bug#46827: Broken initial size of GTK3 frame, Eli Zaretskii, 2021/03/02
- bug#46827: Broken initial size of GTK3 frame, martin rudalics, 2021/03/02
- bug#46827: Broken initial size of GTK3 frame, Eli Zaretskii, 2021/03/02
- bug#46827: Broken initial size of GTK3 frame, martin rudalics, 2021/03/03
- bug#46827: Broken initial size of GTK3 frame, Eli Zaretskii, 2021/03/03
- bug#46827: Broken initial size of GTK3 frame, martin rudalics, 2021/03/03
- bug#46827: Broken initial size of GTK3 frame, Eli Zaretskii, 2021/03/06
- bug#46827: Broken initial size of GTK3 frame, martin rudalics, 2021/03/06
- bug#46827: Broken initial size of GTK3 frame,
Stephen Berman <=
- bug#46827: Broken initial size of GTK3 frame, martin rudalics, 2021/03/02
- bug#46827: Broken initial size of GTK3 frame, martin rudalics, 2021/03/01
bug#46827: Broken initial size of GTK3 frame, Eli Zaretskii, 2021/03/01
bug#46827: Broken initial size of GTK3 frame, martin rudalics, 2021/03/01