bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#62352: Very slow scroll-down-line with a lot of text properties


From: Eli Zaretskii
Subject: bug#62352: Very slow scroll-down-line with a lot of text properties
Date: Sat, 25 Mar 2023 17:02:12 +0300

> Date: Sat, 25 Mar 2023 14:41:04 +0100
> Cc: gregory@heytings.org, 62352-done@debbugs.gnu.org
> From: Herman, Géza <geza.herman@gmail.com>
> 
> >> 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.
> I'm not saying that this is the solution. I just wanted to point out 
> that emacs does unnecessary work.

How can Emacs know that this is "unnecessary work"?  You cannot know
if the buffer contains any composable characters unless you search for
them and fail to find them.

> Note, even with this code commented 
> out, composition still seems to work. Maybe it's buggy, of course.

If you comment out the call to find_composition, prettify-symbols-mode
will stop working, and likewise any other features that use the
'composition' text property.

> But the point is, it seems possible to fix this performance issue.

yes, it is possible to make the Emacs display faster by removing some
of the features it provides.  But that is hardly the right way of
"fixing" performance problems.

> But saying that this issue is not a (performance) bug is not
> correct, in my opinion.

That's not what I said, though.

> > Get a faster computer, or make your keyboard auto-repeat rate lower?
> Maybe there is a 2x single-thread performance factor between my computer 
> and a current fast consumer desktop PC. It is highly unlikely that 
> getting a faster computer will solve this problem.

My computer is a 10-year old machine.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]