bug#61667: 29.0.60; Failure to redisplay

[Eli Zaretskii]

> Date: Thu, 23 Feb 2023 22:05:52 +0200
> Cc: luangruo@yahoo.com, 61667@debbugs.gnu.org, gregory@heytings.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 23/02/2023 21:24, Eli Zaretskii wrote:
> >> Date: Thu, 23 Feb 2023 21:12:42 +0200
> >> Cc:luangruo@yahoo.com,61667@debbugs.gnu.org,gregory@heytings.org
> >> From: Dmitry Gutov<dgutov@yandex.ru>
> >>
> >>>> - 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?
> >> Probably not: in this scenario I usually wait for the frame to finish
> >> resizing, rendering, etc, and for*scratch*  to be displayed properly,
> >> and then I press 'a'.
> > And without double-buffering you see no such delays?
> 
> Yep: as soon as I add
> 
>    --eval "(modify-frame-parameters nil '((inhibit-double-buffering . t)))"
> 
> to the command line invocation, the effect disappears.
> 
>  > not even the
>  > short ones of 100ms?
> 
> It might be more like 200-300ms, by the way.

Sounds like for some reason we don't swap the back buffer to the
screen?  Po Lu, is there any reason which could delay or prevent that?
Like perhaps we decide that the updated frame is not up-to-date or
something?