bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS

[Eli Zaretskii <eliz@gnu.org>]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 30 Apr 2023 12:48:05 -0400
> Cc: luangruo@yahoo.com, 63187@debbugs.gnu.org
> 
> On Sun, Apr 30, 2023 at 11:26 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > scrolling_window is not about scrolling.  It's a redisplay
> > optimization that attempts to speed up redrawing a window by scrolling
> > on display the stuff already shown, when that is deemed less costly
> > than redrawing every screen line that has changed.
> 
> Ah, so is it used (for example) when you insert a newline in part of a
> buffer?

Could be, yes.  But one can never be sure, because the display engine
has many different optimizations, so it could be that this particular
case is handled elsewhere, for example in try_window_id, which also
handles cases like this one.

> How might I reproduce a usage of it both so I can benchmark and play
> around with it when it is enabled to see if I can trigger the bug
> I'm seeing?

The best idea I have is to add a printf right before the mainline of
its algorithm, after this comment:

  /* Reallocate vectors, tables etc. if necessary.  */

and pay attention which edits cause that printf.