bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Mon, Dec 14, 2020 at 06:12:01PM +0200, Eli Zaretskii wrote:
> 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.

I don't see any flickering. I only see the performance reduction when
multiple frames are open.

That happens because drawing to the glass is slow, and the more we
draw to the screen, the longer it takes. When scrolling frame A, frame
B (and C, and D, etc., etc.) has its internal border and cursor(s)
redrawn.

If we MUST redraw these when nothing on the frame is to be updated,
then I don't see there's very much we can do. I've spent a lot of time
trying to improve performance of drawing to the screen and I don't
have the knowledge required to improve it any further.

I think our only next step is to move to hardware acceleration, but
that's not available on a Free system, afaict, so is banned, and I
don't know how to go about doing that anyway.

For the record: redrawing the internal border will cause all versions
of the NS port to redraw the entire frame, because Cocoa only allows
you to select rectangles to redraw, and it joins any contiguous
rectangles together into bigger rectangles, and the internal border
forms a rectangle containing the entire frame contents.

Perhaps I should get rid of the internal border code, it's new to the
NS port in Emacs 28.

-- 
Alan Third