GNU bug report logs - #61667
29.0.60; Failure to redisplay

Previous Next

Full log

Message #128 received at 61667 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: Re: bug#61667: 29.0.60; Failure to redisplay
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:luangruo <at> yahoo.com,61667 <at> debbugs.gnu.org,gregory <at> heytings.org
>> From: Dmitry Gutov<dgutov <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.