[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46827: Broken initial size of GTK3 frame
From: |
martin rudalics |
Subject: |
bug#46827: Broken initial size of GTK3 frame |
Date: |
Tue, 2 Mar 2021 11:02:19 +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?
>
> 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, (continued)
- 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, 2021/03/02
- bug#46827: Broken initial size of GTK3 frame,
martin rudalics <=
- 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