GNU bug report logs - #62352
Very slow scroll-down-line with a lot of text properties

Previous Next

Package: emacs;

Reported by: "Herman, Geza" <geza.herman <at> gmail.com>

Date: Tue, 21 Mar 2023 20:03:02 UTC

Severity: normal

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

Bug is archived. No further changes may be made.

Full log


Message #25 received at 62352-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: geza.herman <at> gmail.com
Cc: gregory <at> heytings.org, 62352-done <at> debbugs.gnu.org
Subject: Re: bug#62352: Very slow scroll-down-line with a lot of text
 properties
Date: Sat, 25 Mar 2023 15:42:20 +0300
> Date: Sat, 25 Mar 2023 13:33:53 +0100
> Cc: 62352-done <at> debbugs.gnu.org
> From: Herman, Géza <geza.herman <at> gmail.com>
> 
> There is a behavior difference. I'm not sure what the exact reason is, 
> but the two different scrolls behave differently.
> 
> With a more complex case (~250 lines, each line is 150 characters long), 
> I can scroll "normally" from the bottom to the top in ~5 seconds (with 
> scroll-conservatively=101). The scrolling stutters. If I disable 
> font-lock, it won't get any faster, still ~5 seconds (but fluid).

Like I said: the threshold where it starts stuttering depends on many
local factors.  Basically, the code does a very similar job, except
that in one case it needs to determine the window's starting position,
while in the other it doesn't (so the jobs the code does are somewhat
different).

> I analyzed the issue little bit, the root cause of the slowdown is 
> composition handling (yet the composition feature is completely unused 
> by this example).
> 
> If I comment out these lines in composition_compute_stop_pos(), emacs 
> works better ("normal" scrolling becomes completely fluid, 
> scroll-down-line still freezes, but for a much shorter time):
> 
>    /* if (charpos < endpos */
>    /*     && find_composition (charpos, endpos, &start, &end, &prop, 
> string) */
>    /*     && start >= charpos */
>    /*     && composition_valid_p (start, end, prop)) */
>    /*   { */
>    /*     cmp_it->stop_pos = endpos = start; */
>    /*     cmp_it->ch = -1; */
>    /*   } */
> 
> It seems that emacs does a huge amount of redundant work by scanning 
> approximately the same area over and over again for composition properties.

This is a non-starter, unfortunately: the display engine _must_
support character composition, or else some scripts will display
incorrectly, and some features (like prettify-symbols-mode) will stop
working.

If you never need to display scripts which require character
composition, turn off auto-composition-mode in your local
configuration (but then expect incorrect display with some
characters).

> I'm not sure how it is possible that you don't see any stuttering with 
> scroll-down-line. On my system it freezes for seconds with my original 
> example (and others can also reproduce it).

Get a faster computer, or make your keyboard auto-repeat rate lower?




This bug report was last modified 2 years and 117 days ago.

Previous Next


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