bug#61667: 29.0.60; Failure to redisplay

[Eli Zaretskii]

> Date: Thu, 23 Feb 2023 18:46:38 +0200
> Cc: Po Lu <luangruo@yahoo.com>, 61667@debbugs.gnu.org,
>  Eli Zaretskii <eliz@gnu.org>
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> The most prominent case of this problem is when the display is not 
> updated for a while, for 1-2 seconds or more. But the less apparent 
> scenario is when the delay between the title bar update and the buffer 
> display is on the order of 100-200ms. And I've probably been seeing this 
> one for a while. Just chalked it up to disk latencies, or GC, or whatever.
> 
> >> if I manage to bisect my config to find something relevant, I will 
> >> report back, of course.
> >>
> > 
> > That was the next thing I was about to suggest: try to bisect your 
> > config to produce a MRE.
> 
> Here's one repro:
> 
> emacs -Q --eval "(tool-bar-mode -1)" --eval "(menu-bar-mode -1)" --eval 
> "(scroll-bar-mode -1)" --eval "(global-set-key \"a\" (lambda () 
> (interactive) (find-file \"test.c\")))"
> 
> Where "test.c" is the name of a file in the current dir. Different files 
> can work, but for some the repro doesn't happen, like those, apparently, 
> which start with a paren (which makes show-paren-mode trigger its own 
> redisplay).
> 
> So, to repro:
> 
> - Run the command above
> - Press "a"
> - Look for the delay between the title bar and the window updates
> 
> With the above 'emacs -Q' it's not as prominent as with my config, but 
> it can reach what looks like 100-200ms. Once every 10 tries or so.

Isn't that the 100-ms delay we wait for the initial frame to finish
displaying, since that requires that we receive some messages from X?

So I'm not sure this is the same problem.  Unless, that is, in the
"problematic" cases we somehow miss the message which we are waiting
for?