GNU bug report logs - #42406
Mouse-wheel scrolling can be flickering

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: konrad.podczeck <at> univie.ac.at, 42406 <at> debbugs.gnu.org
Subject: bug#42406: Mouse-wheel scrolling can be flickering
Date: Mon, 14 Dec 2020 18:12:01 +0200

> Date: Sun, 13 Dec 2020 19:46:04 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: konrad.podczeck <at> univie.ac.at, 42406 <at> debbugs.gnu.org
> 
> Which I've not found very useful. I had a look at redisplay_internal
> to see if I could work out why the frame is being updated, but I
> can't.

AFAIU, it is updated because update_mode_lines is non-zero.

> I looked at some of the variables in redisplay_internal that are
> involved in making the decision whether to check all frames:
> 
> (lldb) p update_mode_lines;
> (int) $0 = 42
> (lldb) p windows_or_buffers_changed
> (int) $1 = 2
> 
> but I have no idea if this is useful at all.
> 
> Is there anything specific you'd like me to check?

I think the issue is clear: mouse-scroll calls scrolling commands, and
all of the scrolling commands set update_mode_lines.  Why they do that
is explained by the comment in wset_update_mode_line:

  /* If this window is the selected window on its frame, set the
     global variable update_mode_lines, so that gui_consider_frame_title
     will consider this frame's title for redisplay.  */

We need to update the mode lines due to scrolling, because mode lines
show the buffer position and other related info.  And please keep in
mind that the frame title can use almost any %-construct defined for
the mode line, so we may need to recompute it as well, when we scroll.
And there's no mechanism in redisplay to redraw portions of the frame
(i.e. something that doesn't belong to any window) except by setting
consider_all_windows_p non-zero.  The effect of that is to consider
all the windows on all the frames for redisplay.  But while Emacs can
refrain from actually redrawing on the glass the parts that it
controls (text displayed in the window etc.), it cannot refrain from
redrawing the parts that are under the control of the GUI toolkit or
the VW.  Which is why you see some portions of the frame flicker.

IOW, the flickering in this case is expected, and cannot be avoided
without making the display engine more fine-grained wrt which parts
need redrawing and when.  The usual method of avoiding flickering is
by double-buffering, but that isn't supported on NS, is it?

However, this bug report said that scrolling becomes slower and slower
with time, and that is not expected, and I see no direct relation
between that and flickering.  Can we please go back to that aspect of
the problem?  It shouldn't happen.

Previous Next

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