bug#61667: 29.0.60; Failure to redisplay

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 24 Feb 2023 15:12:53 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: Po Lu <luangruo@yahoo.com>, 61667@debbugs.gnu.org,
>  Eli Zaretskii <eliz@gnu.org>
> 
> 817dd546497aadefbe9acc8762e3f7190799c5e6 is the first bad commit
> commit 817dd546497aadefbe9acc8762e3f7190799c5e6
> Author: Stefan Kangas <stefan@marxist.se>
> Date:   Sun Sep 13 18:24:31 2020 +0200
> 
>      Improve frame-title-format and icon-title-format
> 
>      * src/xdisp.c (syms_of_xdisp): Replace 'invocation-name' with the text
>      "%b - GNU Emacs" and replace "@" with " at ".  (Bug#41147)
>      * etc/NEWS: Announce the above change.
> 
>   etc/NEWS    | 11 +++++++++++
>   src/xdisp.c |  3 +--
>   2 files changed, 12 insertions(+), 2 deletions(-)
> 
> Triple-checked that as well: the commit before it doesn't reproduce the 
> above scenario, and this one does.
> 
> Looking at the commit, there is another difference in behavior too:
> 
> - With this commit, all is as described previously: I press 'a', window 
> title changes, there is a delay (randomly), then the window contents change.
> 
> - 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?

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?