GNU bug report logs - #63187
30.0.50; Tail of longer lines painted after end of nearby lines on macOS

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Sun, 30 Apr 2023 10:11:01 UTC

Severity: normal

Found in version 30.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 63187 <at> debbugs.gnu.org
Subject: bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS
Date: Sun, 30 Apr 2023 12:48:05 -0400
On Sun, Apr 30, 2023 at 11:26 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen <at> gmail.com>
> > Date: Sun, 30 Apr 2023 10:57:35 -0400
> > Cc: luangruo <at> yahoo.com, 63187 <at> debbugs.gnu.org
> >
> > For what it's worth, disabling it has had no discernible impact on
> > scroll performance on my machine (which is an M1)
>
> 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? 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?




This bug report was last modified 1 year and 364 days ago.

Previous Next


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