From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#61667: 29.0.60; Failure to redisplay Date: Fri, 24 Feb 2023 23:03:12 +0200 Message-ID: <17adc089-9773-0e1c-8345-1f289e3285a4@yandex.ru> References: <04d7cb31-684c-07c0-ee7b-503514fc1a85@yandex.ru> <87a617eanz.fsf@yahoo.com> <4306cb76-a44c-3101-e43c-fd64afae4a51@yandex.ru> <871qmje2ws.fsf@yahoo.com> <83edqjtbss.fsf@gnu.org> <4e5e2a46-9b07-206a-6774-9f98f34cbd14@yandex.ru> <83y1orrolh.fsf@gnu.org> <83sfeyswdw.fsf@gnu.org> <877cwactgv.fsf@yahoo.com> <83mt55sxli.fsf@gnu.org> <8afe34f2-eeea-3be8-82ef-576a115beb6d@yandex.ru> <96b742a05da174ece02e@heytings.org> <25c48260-2edc-f062-8fef-52ff2fdd22e3@yandex.ru> <96b742a05dea855f9636@heytings.org> <853eca8f-5850-dd73-7601-4fad92613ab9@yandex.ru> <0a7313f0-765c-aeca-ae50-6d8adbfb04ed@yandex.ru> <83cz5znpko.fsf@gnu.org> <838rgnnlt0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1572"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Cc: luangruo@yahoo.com, 61667@debbugs.gnu.org, gregory@heytings.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 24 22:04:16 2023 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 1pVfEm-0000D7-5r for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Feb 2023 22:04:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVfEa-0004CE-Mn; Fri, 24 Feb 2023 16:04:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVfEY-0004Bz-E7 for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 16:04:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVfEY-0000mA-6U for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 16:04:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pVfEY-0001qJ-24 for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 16:04:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Feb 2023 21:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61667 X-GNU-PR-Package: emacs Original-Received: via spool by 61667-submit@debbugs.gnu.org id=B61667.16772726037031 (code B ref 61667); Fri, 24 Feb 2023 21:04:02 +0000 Original-Received: (at 61667) by debbugs.gnu.org; 24 Feb 2023 21:03:23 +0000 Original-Received: from localhost ([127.0.0.1]:38361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVfDv-0001pK-06 for submit@debbugs.gnu.org; Fri, 24 Feb 2023 16:03:23 -0500 Original-Received: from mail-wr1-f43.google.com ([209.85.221.43]:40771) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVfDt-0001p6-65 for 61667@debbugs.gnu.org; Fri, 24 Feb 2023 16:03:21 -0500 Original-Received: by mail-wr1-f43.google.com with SMTP id t15so428544wrz.7 for <61667@debbugs.gnu.org>; Fri, 24 Feb 2023 13:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=PuNsm4MjZ2m61D/sikqFzgSgnbT/tJa8RIh/DmNp07A=; b=BRkVfXjS37ftXYk+9WXm1rU1AZP96qzv/7gV3n37dslxvpCWTLn5dk2BFrc/O7+4MZ DXmcDukWDiai3hmzzdRyszeUSzIZq5OK0FeAfx7Qjc9fw+YVKXrYX/pswfmGssNmDSVz jonE7Id/BAPmup2kCW7g9DXNw4pA1VUm9GfZY+6aL/zOeLjz1HejitD4P2uQqc5IigUv txVmNZooBtAUeCSr9+ljCGWvGpkeA2ahWlgICdqEHpe2FZY29kd6SH9VOJdSVjXoJlCc f5p1Pgp76Nb6yeiHCFnYxK6CVhd+kCJfz4NSscOKwrQyOxEYHLkDAXNFyIJ8r+BaLFgN qBCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PuNsm4MjZ2m61D/sikqFzgSgnbT/tJa8RIh/DmNp07A=; b=1eVRUOL2gxBPnchoOThfyXcrjM4LCHPpRZQLdNvo8LkbQ7LwmsoPRSEu1//7xeBuKk 5ohKeGlCKGpSMMeiGw4lUNNCAAuFlpknlEWx62IvdvpI0dJ2krESi3LXAdJs90gCxG6i Imm8PDgXWwuApbu/UXzQKv5k86AnvlnPc5QM/65WUpVFluQTLYU47G3By7+Nui+DA56Y PibHmogGkg4aqNKZDNmDNUcmOurxWAo1verBgD9oPKSMN0XmIyUeL+qGNTuNCvoJkq+3 36qfLDZChWzN08Dn3WT2WPifJaeR+l0Anj6c2/GzQq5GK8Jqgt1WzOi4uCqezPuIGeX6 mFSQ== X-Gm-Message-State: AO0yUKXOlOXLoi29t5VKQA3M/nSfAv+fTbiyV/doyhQsQNla1YpdRrZu cPeTbjqoFLj0qVDIt/b6n4E= X-Google-Smtp-Source: AK7set9H7W3wm5UTmCqfWTuWbrgCMTRWL/Q1MQm9HRG7CLG1KT4epjBzzD9OfbQWR2V2xxKK+gRccQ== X-Received: by 2002:adf:f4cb:0:b0:2c5:530b:7d6d with SMTP id h11-20020adff4cb000000b002c5530b7d6dmr16291618wrp.24.1677272594959; Fri, 24 Feb 2023 13:03:14 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id b9-20020a5d4b89000000b002c794495f6fsm1941089wrt.117.2023.02.24.13.03.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Feb 2023 13:03:14 -0800 (PST) Content-Language: en-US In-Reply-To: <838rgnnlt0.fsf@gnu.org> 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:256660 Archived-At: On 24/02/2023 17:08, Eli Zaretskii wrote: >> Date: Fri, 24 Feb 2023 16:12:30 +0200 >> Cc: luangruo@yahoo.com, 61667@debbugs.gnu.org, gregory@heytings.org >> From: Dmitry Gutov >> >>>> - Before this commit: the window title doesn't change, it's always >>>> emacs@hostname. But when I press 'a' (bound to 'find-file' lambda), >>>> there never is a noticeable delay before the window contents change. The >>>> buffer is displayed instantly. >>> How is this consistent with your previous finding that the problem >>> exists in Emacs 25, 26, and 27. The change above is only present in >>> Emacs 28. Does this mean that the problem 100-200ms delay and the >>> original problem are two different problems? >> >> Easy: my configuration contains a customization for frame-title-format. >> >> It's set to >> >> (setq frame-title-format '(buffer-file-name "%f" ("%b"))) >> >> All the time I spend bisecting the config I didn't think to change it >> (it's the very first line). And this makes the problem appear with Emacs >> 27 and 26 too. > > So the hypothesis now is that changes in the frame's title, which > cause Emacs to update the title by issuing GTK and/or X calls, somehow > cause the problem, is that right? I suppose so. >>> Anyway, if the changes in the frame's title are somehow related to >>> this, their effect is to cause Emacs to call x_set_name_internal to >>> display the new title. Could it be that this function takes such a >>> long time to execute? Or does it have some strange effect on the WM? >> >> My vague (and likely wrong) guess would be that the WM knows it needs >> some update from the Emacs window, gets it from the title bar before >> everything else, and marks the update as completed. > > Can you please time that function anyway, if only to make sure the > problem is elsewhere? How much time does it take x_set_name_internal > since its call till it returns, when it actually changes the frame's > title? Okay, done. It was a reasonable guess, that if the update is synchronous, it might stall for some reason. But that doesn't seem to be the case. It takes about the same time when the bug manifests as when it does not: [x_set_name] time to x_set_name_internal: 49 [x_set_name] time to x_set_name_internal: 20 Here's the patch I used, if you want to check or modify it: diff --git a/src/xfns.c b/src/xfns.c index 528ae61ca32..b8ce75469c7 100644 --- a/src/xfns.c +++ b/src/xfns.c @@ -2238,6 +2238,13 @@ x_set_name_internal (struct frame *f, Lisp_Object name) } } +int64_t now_millis() { + struct timespec now; + timespec_get(&now, TIME_UTC); + + return ((int64_t) now.tv_sec) * 1000 + ((int64_t) now.tv_nsec) / 1000; +} + /* Change the name of frame F to NAME. If NAME is nil, set F's name to x_id_name. @@ -2290,7 +2297,11 @@ x_set_name (struct frame *f, Lisp_Object name, bool explicit) if (! NILP (f->title)) name = f->title; + int64_t was = now_millis(); + x_set_name_internal (f, name); + + fprintf (stderr, "[x_set_name] time to x_set_name_internal: %ld\n", now_millis() - was); } /* This function should be called when the user's lisp code has @@ -2330,7 +2341,11 @@ x_set_title (struct frame *f, Lisp_Object name, Lisp_Object old_name) else CHECK_STRING (name); + int64_t was = now_millis(); + x_set_name_internal (f, name); + + fprintf (stderr, "[x_set_title] time to x_set_name_internal: %ld\n", now_millis() - was); }