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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 61667 <at> debbugs.gnu.org, Gregory Heytings <gregory <at> heytings.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#61667: 29.0.60; Failure to redisplay
Date: Wed, 1 Mar 2023 03:25:05 +0200

On 01/03/2023 03:11, Po Lu wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
> 
>> Why does constant frame-title-format fix this, though?
> 
> Because presumably Mutter has no need to damage the title bar, which you
> do see changing.
> 
>> I have tried this with default config (double buffering on,
>> undecorated off), and I don't see any delay between text insertion and
>> frame title changes. 1 second pause, "Test 1" is inserted, the title
>> changes (*), 1 second pause, "Test 2" is inserted, the title changes.
>>
>> That probably means I don't need to test the alternative configs,
>> right?
> 
> Yes, but that's odd.  What if you run the entire test in an infinite loop?
> Do you eventually notice a delay?

Originally I ran the test a couple of dozen times (restating Emacs every 
try), like I do with the MRE scenario when testing different settings.

Now I re-ran it with (dotimes (i 20) ...) twice, and didn't see the 
problem either.

Not sure how infinite you want this loop to be, but the original 
scenarios would almost certainly have showed the problem several times 
over this many tries.

>> (*) By default frame-title-format is eq to icon-title-format, so with
>> 'emacs -Q' the title doesn't actually change on the first step. I
> 
> The idea was to restore the original frame-title-format, yes; it was
> supposed to be run in a loop as well.

All right.

Previous Next

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