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

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 61667 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, gregory <at> heytings.org
Subject: Re: bug#61667: 29.0.60; Failure to redisplay
Date: Fri, 24 Feb 2023 16:29:10 +0200

On 24/02/2023 15:58, Po Lu wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
> 
>> I vaguely recall them talking about such problem and working on it,
>> from certain dev blogs. Though I though it was supposedly fixed in
>> GNOME 43.1 (which I'm using).
>>
>> But how does it relate to our situation? If GNOME refreshes windows
>> more often that it has to, then it's a performance problem for them
>> (re-rendering takes cycles), but not a correctness problem.
>>
>> The only things it should do to us, is helping to mask our problem
>> (when Emacs doesn't refresh quickly enough) by forcing additional
>> repaints.
> 
> The problem is that I suspect Mutter is forgetting to queue a buffer
> flip or to update its back buffer with Emacs's window contents, since
> judging by the logs you sent, Emacs is making the same buffer swapping
> requests regardless of whether or not the bug can be reproduced.
> 
>>> But before you do so, please try the following:
>>>     - Use a less resource intensive testing program (not Firefox or
>>>       Telegram Desktop) such as ``xclock -update 1''.
>>>     - Update to the latest version of GNOME Shell.
>>
>> I can reproduce the bug when the Emacs window covers xclock.
> 
> Right, what if you move xclock so only half of the clock is obscured?

If both of these are true:

- xclock is only partially obscured (half-ish).
- The updated frequency is high (xclock -update 0.001)

then I can't reproduce the problem anymore.

If either is false (e.g. if I'm using 'xclock -update 1'), then the 
problem reproduces still, albeit with a little lesser frequency.

> Also, when you run ``xprop'' and then click on Emacs's window, what is
> the value of the property _NET_WM_OPAQUE_REGION?

_NET_WM_OPAQUE_REGION(CARDINAL) = 0, 0, 1456, 1296

> Another idea would be to place a constantly updating transluscent window
> on top of Emacs, which will force mutter to copy the up-to-date contents
> of the frame in to its back buffer.  But I know of no easy test program
> for that, I might write one tomorrow.

Thank you.

Previous Next

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