Subject: bug#77039: 31.0.50; Flickering on macOS

From: "Aaron Jensen" <[email-masked]>
Date: Sun, 23 Mar 2025 16:03:17 +0000

On Sun, Mar 23, 2025 at 3:37 AM, Eli Zaretskii < [email-masked] > wrote:

> 
> 
>> 
>> 
>> Cc: gerd. moellmann@ gmail. com ( [email-masked] ) , alan@ idiocy.
>> org ( [email-masked] ) , 77039@ debbugs. gnu. org ( [email-masked]
>> ) Date: Sun , 23 Mar 2025 12:13:10 +0200
>> From: Eli Zaretskii < eliz@ gnu. org ( [email-masked] ) >
>> 
>> 
>> 
>> So in summary, I don't see anything abnormal here. If we want to keep the
>> only-current-line-changed optimization in redisplay_internal, someone will
>> have to come up with a smarter test for when line numbers are shown. I
>> think the underlying problem is that when the line number of the current
>> line becomes large enough to require more columns for line-number display,
>> we must redraw the entire window to avoid the problem with shifting or
>> line number described in https:/ / debbugs. gnu. org/ cgi/ bugreport. cgi?bug=54091#5
>> ( https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54091#5 ).
>> 
>> 
>> 
> 
> 
> 
> To clarify: this should not cause any flickering, AFAIU, because the
> comparison of glyphs in subroutines of update_frame is supposed to find
> that everything on the glass is already up-to-date and there's no need to
> draw anything. So flickering, which happens because portions of the window
> are actually redrawn on the glass, should not happen in this case.
> 
> 
> 
> 

Right, I don't observe any flickering. Am I correct that it is only comparing the glyphs on the current line? If so, that doesn't seem like a huge problem, even though it is (in most cases?) technically extra work.

Aaron