bug#61667: 29.0.60; Failure to redisplay

[Dmitry Gutov]

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.