Subject: bug#61667: 29.0.60; Failure to redisplay

From: Dmitry Gutov <[email-masked]>
Date: Thu, 23 Feb 2023 22:05:52 +0200

On 23/02/2023 21:24, Eli Zaretskii wrote:
>> Date: Thu, 23 Feb 2023 21:12:42 +0200
>> Cc:[email-masked],[email-masked],[email-masked]
>> From: Dmitry Gutov<[email-masked]>
>>
>>>> - 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.