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

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 46827 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>
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

Previous Next

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