bug#61667: 29.0.60; Failure to redisplay

[Po Lu]

Dmitry Gutov <dgutov@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?
Also, when you run ``xprop'' and then click on Emacs's window, what is
the value of the property _NET_WM_OPAQUE_REGION?

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.