On Tue, Mar 18, 2025 at 9:52 AM, Eli Zaretskii wrote: > From: Aaron Jensen > Date: Tue, 18 Mar 2025 15:32:41 +0000 > Cc: Gerd Möllmann , alan@idiocy.org, 77039@ > debbugs.gnu.org > > Yes, redisplay should be a nop, since the buffer which is modified is not > displayed. > > But Aaron seems to say we keep comparing the glyph matrices of the window > which is not show, something that should not happen, because we don't call > update_frame on frames that are not visible. > > I tried to explain that I wasn't convinced that it was that, that it could > have, and even likely was, a redisplay of the currently displayed buffer > (which is why *it* was flickering). Unless anyone thinks that there is > reason to investigate further, I'm satisfied with the answer that reading > process output can cause a comparison of glyphs, which is unlikely to > result in a redisplay of an unrelated buffer. > > Reading process output is not supposed to cause comparison of glyphs if > the buffer to which process output is directed is not being displayed. So > if you do see glyphs being compared in that case, we should look into that. > The only glyphs that could be legitimately compared in that case are those > on the mode line. > In my config, I definitely see matrix comparisons when hidden buffers are updated. It's row_equal_p and update_text_area that are called in rapid succession even when the shell buffer is not visible. I tried disabling both my tab bar and my header line (I don't use a mode line) and I still saw it updating. Here's an example log output, this repeats as quickly as yes emits "y" dispnew.c:4775 dispnew.c:1295 dispnew.c:1295 dispnew.c:1295 dispnew.c:1295 dispnew.c:1295 dispnew.c:1295 dispnew.c:1295 dispnew.c:4775 I can't reproduce this with emacs -Q, unfortunately. It seems to be have as you described. Hidden buffers do not cause comparisons. Aaron