From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#46827: Broken initial size of GTK3 frame Date: Tue, 02 Mar 2021 10:17:17 +0100 Message-ID: <87r1kxvrs2.fsf@gmx.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34869"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 46827@debbugs.gnu.org, Robert Pluim To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 02 10:18:10 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 1lH1AP-0008vf-Ms for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Mar 2021 10:18:09 +0100 Original-Received: from localhost ([::1]:49686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lH1AO-0007aG-Nl for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Mar 2021 04:18:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36368) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lH1AI-0007a6-GS for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 04:18:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40293) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lH1AI-0007pz-96 for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 04:18:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lH1AI-0008MZ-5P for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 04:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Mar 2021 09:18:02 +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.161467665632116 (code B ref 46827); Tue, 02 Mar 2021 09:18:02 +0000 Original-Received: (at 46827) by debbugs.gnu.org; 2 Mar 2021 09:17:36 +0000 Original-Received: from localhost ([127.0.0.1]:51839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH19s-0008Lw-HM for submit@debbugs.gnu.org; Tue, 02 Mar 2021 04:17:36 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:35847) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH19q-0008Li-6Q for 46827@debbugs.gnu.org; Tue, 02 Mar 2021 04:17:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1614676647; bh=wV1NZaHrBUNXhhFwsOrM7nXCjy2TklUIjuDjlPHfeV0=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=jqLq5JXxD7crcWeQYEMMw79yhTgf8ufc8CPcb8m+QGOkcdfI1v8V2TCg36dY/iFoq zmgSzJX8FBf/rpEd+cmxxWwT6SZBNLBAC5L0dBHoytUzlvbO/9LmlXfodBcWx9PJPK YOkcZnkgzPdn4oZltKLB4X2Yi500ohvB1/hXr2xk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from strobe-jhalfs ([188.109.200.178]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MpUZ4-1lZuxv1N9w-00px5K; Tue, 02 Mar 2021 10:17:27 +0100 In-Reply-To: <689ba08c-639f-af40-5c30-95dcceac552f@gmx.at> (martin rudalics's message of "Tue, 2 Mar 2021 09:24:38 +0100") X-Provags-ID: V03:K1:YJV1I6kuCn/12qfUCNLg+S43FiEmMzDLROzeVCgz/SYHoUOKY4t lTAwjNHI/9wCv3cVn55RM86FNrq0y8wEKRPuvuvZByDgVeE+AcFZIImo+mUvCS8OCj9c4ov nWFSz/ruiRwSJqK0hetFNEPrmGLFt9nq29TQ9/S4kY6eq7KpFtjAwCWAEeeQmaaoFVP3dDy 0GpqYZcFdoDSI8bVydIIw== X-UI-Out-Filterresults: notjunk:1;V03:K0:FHWXbgG9FDI=:O/Pp8AHz0v/hr+kK8+/6GZ 6RBSN42tUbMVXNWpGERZeWayzzUJY4/C91dF+tmmqXeiyD1FvL8EWwR1p4KQW9vo6m945kTHa xLxtwUmlaQadENNkPb18XyHO2h/sPvlGs5pATs0UD4N+xkMb/YiJdel0I1eHtJjYHOgt0qkH6 f1hBkL4HQkILnGfphqY4C2ZwKLpNzxuIMPa9NoIDx0AoEK+2EX/jnw26CkSzve6lrXyhxfDto qCeVSy/Z0xSszuvhe7hxDndFb6vNvk+ghd8iapcOhg6lPC/vSjddpKptdejn0L6PB9jeZjbsR Aj9ByZG1s2hOCR2IM0g6xY8IJ1xWnXxypRh2NeYVA5ctDpoW9hItY9bdN+MoqgPYhK+3KrFQ0 YRjMdORfmRzfTe4hHnMXPUTRH8uNxPY6zwXU4tiI6Srk53FabTtGJkkP8e5FjE0nE0jmYZ89q d3+Eu87YTfVUCHdmDdQjBBWL0sa1/76+iB1bwlHAUYrQvurnKr5AhMj27YLumaR5rG0n1XCw/ 6v6nlrWuJqgW1e0TBaHhj69lixCa2VbfYhN4UJArNfJmGIVeXC5zJr3FFqPkzAdD0MsuIq22a ixFVbAsF8NL+inXUgXM1CN5r2Eu2Mniq1r06307xSR4sZYsVhQhWYfun9q/78Y1YoX24esoVx 8CtWcPw7zJYteUKTVSjEanYo/ycCoX2rJpO4O5nOPAoZgu46xKMsCgfvXkxdX8VaIp8nN3Uyh 7MlIG+3VGwU8iBQ1/VnN+P/17KPI/OvXi86Oj+lD5I5OCi4zVQfar0XaOx5KE6yivxj2Qi7Q 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:201201 Archived-At: (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 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=CA=BCs 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