From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#46827: Broken initial size of GTK3 frame Date: Tue, 2 Mar 2021 11:02:19 +0100 Message-ID: References: <6caa020a-084c-e3f2-7a34-262f7127b21b@gmx.at> <87eegz41ui.fsf@gmail.com> <875z2b3srx.fsf@gmail.com> <87ft1fyo88.fsf@gmail.com> <8a346498-e7e3-ca92-e518-86f6fc2c37b7@gmx.at> <87y2f6spgm.fsf@gmail.com> <87v9aaslh9.fsf@gmx.net> <689ba08c-639f-af40-5c30-95dcceac552f@gmx.at> <87r1kxvrs2.fsf@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40427"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46827@debbugs.gnu.org, Robert Pluim To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 02 11:03:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lH1rz-000AOB-Fr for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Mar 2021 11:03:11 +0100 Original-Received: from localhost ([::1]:51656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lH1ry-0007Wk-EC for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Mar 2021 05:03:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48416) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lH1rp-0007UO-TR for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 05:03:01 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40331) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lH1rp-0001td-Lm for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 05:03:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lH1rp-00019m-Ic for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 05:03:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Mar 2021 10:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46827 X-GNU-PR-Package: emacs Original-Received: via spool by 46827-submit@debbugs.gnu.org id=B46827.16146793504378 (code B ref 46827); Tue, 02 Mar 2021 10:03:01 +0000 Original-Received: (at 46827) by debbugs.gnu.org; 2 Mar 2021 10:02:30 +0000 Original-Received: from localhost ([127.0.0.1]:51871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH1rK-00018Y-4U for submit@debbugs.gnu.org; Tue, 02 Mar 2021 05:02:30 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:39775) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH1rI-00018G-RB for 46827@debbugs.gnu.org; Tue, 02 Mar 2021 05:02:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1614679341; bh=ayeeMffxafkrW2DE2x606uqZoH0N6uIG9B3m8z09JFU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ReNPcLg2m3kQhPzU6Z2CeaAzJmvy7kpsw+5zvH5iLQUu+Ryy02Hkd7Y8Tbmcjwp8S VdKspEfQ/nLIkJTLzdM4cI/y5rWhdaNF/PLnSBHx4BAFsl7qfWjZgt2orzLpQemvRM TWKMTOrpPukVf0J/aXJVeUlRZatDPRsMcRJ0NlIc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.69]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M5fMY-1l9tFn2sLy-007Bap; Tue, 02 Mar 2021 11:02:21 +0100 In-Reply-To: <87r1kxvrs2.fsf@gmx.net> Content-Language: en-US X-Provags-ID: V03:K1:sGj+duT3H8/894LxD12SQDcoAssIaElZYuiIHU2IEBSJnx27PUE Fq2rlIb2Q41JUDIcZItgBFwvHIXObhGEMaLc7CuV2T9T3R+Zfbwdo6rVtL9Au7zYxx3f60M qh4EH6wWaiz2yOMud4NzvGqzTM75RmWiEcdem/ureWFlcB2Dg6tefR+1TVr7ErX/aLYnKhQ TNJMLVh5TdLX5BfUapWDQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:sF+Q1AJkaT0=:LhQJnVy0XnYafOpfZ+VI86 QOpBsgHoIatrE9oJgVYongPNiNiAaqPCPpWzPo8QiB+ADCIYESAl9xk7Ig++OofSfolimgFI7 nk6jz6A8J4ZTdlQJeNs0kkSmgJByJ06g8HuM0fYqmQxpAckOVB0aJ6BcyCtC1z7rjyxkqudPD CpSIrAOstPrca6+uBNn1/y35gP7zZZZNyFj7mk6HRE6p6iO8+mcv8yUc+nbYZSVeuunT4YQD1 dQ3FK4e/ZrC813dzscd0gtKpdCeg0s9noxRX8LS7fpDVgE5hc0pdEJEOiLXkkvHBzyNmA6Unc eiUciwr4nX5tt7RYExu2wQde8IN9TiyZmoHWo8RG+jxb5dyKoXNLMrjGscG6viECqsGkcL08S cf4gewl5qViVylfnsaOokcio3dYk6b9/eDEheTwlbqBDerWErJZk6hQf/nelENdWcKalmO0El JLdLrv+oZfbRXFV3/OEYYtP9FdwZXCiyzayw1rnnY7M7mcgyM/SdyxCammzEAfh1FFHapoNjp mDTvTi4Jh4WaWZYpg0Ubc5exkldVBwoIF6i9iFgFW7OGMbhGd91smfjklGdjLpgk0tFUmT4jS n5dAMEYZKsTCUEaFBqV8i3dhNtQwKGbLcJP7DdBTdJtwNB/M6xI+hRn2cntH9seTjdXYP9yfO 1+rAu1yDYdozpOdumT5TC1My6aBjY1pBPa4vlIiWN1BWOx2Rb2iOZ09ocd0JUhmPZ8fRYdLm8 vRBUi1L1qAGimgta2WPKh28wwoVNNguPrwobyhuaaJLwdR8roa/01QKlwqzALIc1rNZiNZ/d X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:201202 Archived-At: >>>> Interestingly, if I run the gtk build under xfwm4 without its dumpf= ile >>>> present, I do sometimes see the frame issue you reported, which >>>> suggests it=CA=BCs a timing issue somewhere. >>> >>> Evidence in favor of that suggestion may be the following observatio= ns: >>> I can reliably reproduce the problematic display (on xfwm4-4.14.1 wi= th >>> GTK+ 3.24.17) with the first invocation below, but not with the seco= nd >>> 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 he= re, >> 0 does not. So the problem still seems that redisplay misses a pendi= ng >> 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 hav= e > 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 se= en > it on others. These observations also suggest to me a timing issue, b= ut > 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