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

Cc: Alan Third <alan@idiocy.org>, 77039@debbugs.gnu.org From: Gerd Möllmann <gerd.moellmann@gmail.com> Date: Mon, 17 Mar 2025 05:20:11 +0100
Aaron Jensen <aaronjensen@gmail.com> writes:
Does that also happen when you use something else than vterm, say M-x shell or M-x eshell?
Yes, it happens with shell and term as well
To me that looks as if this shouldn't happen. At least judging from what I remember from the times of Emacs 21.
Maybe Eli has an idea what could cause this. It might be worth submitting another bug for this.
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?

Is it clear to you why the glyph comparison failing would lead to flickering, even with double buffering enabled?
Heard about the double-buffering feature the first time yesterday, I think. I had it in a branch in Emacs 21, but I guess it's not that one
:-). Or IOW, no idea. It might depend on how that's implemented.
If glyph comparison fails, Emacs will redraw the screen. Whether it should be visible with double-buffering depends on how that was implemented on macOS, and what exactly "flickers" as part of
"flickering".

Ok, then yea it's very possible that the particular method used is susceptible to flickering. Thanks.

Aaron