On Mon, Mar 17, 2025 at 9:38 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Mon, 17 Mar 2025 15:56:00 +0000
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>, alan@idiocy.org, 77039@
> debbugs.gnu.org
>
> If you are talking about comparing glyph matrices of windows/frames that
> are not shown, that shouldn't happen. If it seems to happen, I'd need a
> clear recipe where it does, which I could run on GNU/Linux or MS-Windows,
> to debug this. Windows that are not displayed don't even have desired
> matrices to compare, so I don't think I understand how this could be
> possible.
>
> It's more likely that an update in a hidden buffer is causing a glyph
> comparison on the displayed buffer given that it's the one that is
> flickering. Because the buffer is updating so rapidly, this happens often.
> The hidden buffer is connected to an external process. You can simulate
> this by running `yes` in a `term` and then hiding that buffer. Is that
> expected?
>
> I don't think I understand the situation. If you can show some Lisp to
> simulate that, it would help.
>

Not Lisp, but:

emacs -Q
M-x shell
yes<enter>
C-x b<enter>

This will open a shell in a background buffer that is rapidly printing to
STDOUT (and displaying in the shell buffer) then switch to the scratch
buffer. If you add logging to the matrix comparisons you will see a rapid
uptick. I don't know if this has to do with the external process connection
with Emacs.

To be clear, I don't know if this is actually an issue given that the
matrix comparison is likely preventing the redisplay.

Aaron