bug#61667: 29.0.60; Failure to redisplay

[Eli Zaretskii]

> Date: Fri, 24 Feb 2023 16:12:30 +0200
> Cc: luangruo@yahoo.com, 61667@debbugs.gnu.org, gregory@heytings.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >> - 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?

> > 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?