GNU bug report logs - #77039
31.0.50; Flickering on macOS

Previous Next

Full log

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Alan Third <alan <at> idiocy.org>, 77039 <at> debbugs.gnu.org
Subject: Re: bug#77039: 31.0.50; Flickering on macOS
Date: Sun, 16 Mar 2025 21:20:01 +0000

[Message part 1 (text/plain, inline)]

On Sun, Mar 16, 2025 at 1:13 PM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:

> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> Could you please try if the attached change works for you (without your
> patch)?
>
> I was just about to send you log output that showed seemingly random
> values in glyph::frame. You beat me to it.
>
> 👍
>
> This patch appears to fix the problem for me, thank you.
>
> Thanks.
>
> Is this the only place that they need to be initialized? Was it more than
> glyph::frame that was uninitialized (and was that problematic)?
>
> adjust_glyph_matrix is the only place where these glyph allocations
> happen, for window-systems. For completeness, let be just say that glyphs
> matrices on ttys function differently. And the whole struct glyphs in a
> glyph row were uninitialized because they are allocated via C's realloc. I
> don't think this being uninitialized was a problem before, the problem was
> only the combination with my assumption that the memory was zeroed. Don't
> know where that assumption came from. Maybe I've misread them, or maybe
> it's just that I hate leaving memory uninitialized in general and assumed I
> wouldn't have done it there. No idea.
>
> For my own edification, while logging GLYPH_EQUAL_P, I noticed that it's
> invoked frequently for windows/buffers that are not visible. As in, while a
> hidden vterm buffer is accumulating log output and I only have a single
> stationary buffer visible, I see a flood of log messages. Is this expected?
> It may very well be, I just don't know much about the rendering pipeline.
>
> That sounds suspicious. So you have one window W displaying some innocuous
> buffer B, and another vterm buffer V that is not displayed anywhere. The
> shell in V runs something producing output. That does not change B, and
> also not something visible in W, including mode-line or such or maybe frame
> title. And that leads to some redisplay of W?
>

Yes, all of that is true. I can't say whether or not it leads to a
redisplay of W, I just know right now that it leads to glyph comparisons
and somehow that leads to flickering in W, so maybe that's enough to infer
that it's a redisplay of W.

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

Now pushed. Thanks for the very helpful hint!


Thank you for the quick fix.

Is it clear to you why the glyph comparison failing would lead to
flickering, even with double buffering enabled?

Aaron

[Message part 2 (text/html, inline)]

Previous Next

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