Subject: bug#46827: Broken initial size of GTK3 frame

From: martin rudalics <[email-masked]>
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