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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: alan <at> idiocy.org, 77039 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: Re: bug#77039: 31.0.50; Flickering on macOS
Date: Sun, 23 Mar 2025 10:04:04 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: "Eli Zaretskii" <eliz <at> gnu.org>,  alan <at> idiocy.org,  77039 <at> debbugs.gnu.org
> Date: Sun, 23 Mar 2025 06:41:10 +0100
> 
> "Aaron Jensen" <aaronjensen <at> gmail.com> writes:
> 
> >  Thanks! I think I see now what's going on. 
> >
> >  redisplay_internal has this (line numbers may differ): 
> >
> >  xdisp.c: 
> >  17368 && (NILP (Vdisplay_line_numbers) 17369 || EQ (Vdisplay_line_numbers, Qvisual)) 
> >
> >  This means that certain redisplay optimizations that make redisplay particularly "cheap" are not
> >  tried, depending on line number display. 
> >
> >  Instead the more expensive redisplay methods are used that consider whole windows or parts of them
> >  and so on. Or, in other words, line number display can make redisplay less of a nop. 
> >
> >  So, with line numbers, hidden buffer with process -> wait_reading_process_output ->
> >  redisplay_internal -> update_window (or similar) -> ... -> row_equal_p -> the equal macros
> >
> > My vterm buffers do not have line numbers, so it sounds like it's
> > considering the line number status of the currently visible window,
> > does that sound right?
> 
> Yes, it's the value in current_buffer. Don't see ATM where that is set,
> but it's normally the buffer of the selected window. Maybe that's
> implicitly the case if consider_all_windows is false. 

Of course, it's from the current buffer.  But we forgot the effect of
blink-cursor-mode, which forces a (minor) redisplay cycle every 0.5
sec, and requires to at least redraw the character under the cursor.
So turning off blink-cursor-mode should perhaps prevent the problem.
Does it?

> > And it looks like there's a FIXME comment right above it:
> >
> > ```
> >    /* FIXME: The following condition is only needed when
> > significant parts of the buffer are hidden (e.g., under
> > hs-minor-mode), but there doesn't seem to be a simple way of
> > detecting that, so we always disable the one-line redisplay
> > optimizations whenever display-line-numbers-mode is turned on
> > in the buffer.  */
> 
> Yeah, I've seen that, but I couldn't figure out what circumstance
> prevents using the optimizations in this case, specifically when line
> numbers are displayed. An enigma :-).

Not an enigma: "git annotate" points to a certain bug which was the
trigger for the addition of this condition.

Previous Next

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