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

Previous Next

Full log

View this message in rfc822 format

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: bug#77039: 31.0.50; Flickering on macOS
Date: Sun, 16 Mar 2025 12:37:01 -0700

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

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

> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> Hi,
>
> I've narrowed it down to the addition to frame in the glyph comparison. As
> far as I can tell, the attached patch removes the flickering for me. I saw
> the cursor blink once, but I couldn't reproduce that and I couldn't get it
> to do it again.
>
> The patch is not suitable for applying to master as it certainly breaks
> something int he tty child frame code, but hopefully it gives you an idea
> of what the problem might be. I'm going to experiment with accounting for
> the NULL frame in the space glyph and see if that helps.
>
> Thanks Aaron, that was very helpful. I'm pretty sure it gave me right
> idea, namely... This in adjust_glyph_matrix
>
> dispnew.c:
> 505 while (row < end)
> 506 {
> 507 row->glyphs[LEFT_MARGIN_AREA] = 508 xnrealloc
> (row->glyphs[LEFT_MARGIN_AREA], 509 dim.width, sizeof (struct glyph));
>
> means that glyphs in window-system windows are not zeroed. Which in turn
> means that glyph::frame is not guaranteed to be NULL initially. And because
> I falsely assumed that to be the case, I didn't change the code producing
> glyphs for window-systems to set glyph::frame, which isn't needed or used
> on window-systems. And in the end, the glyph comparisons can fail.
>
> Or so is the hypothesis...
>
> 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.

Is this the only place that they need to be initialized? Was it more than
glyph::frame that was uninitialized (and was that problematic)?

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.

Thanks,

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.