GNU bug report logs - #74813
31.0.50; scroll-down is 10x slower and laggy than scroll-up

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: execvy <at> gmail.com, 74813-done <at> debbugs.gnu.org
Subject: Re: bug#74813: 31.0.50;
 scroll-down is 10x slower and laggy than scroll-up
Date: Tue, 04 Mar 2025 16:22:32 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 3 Mar 2025 19:00:15 -0800
> Cc: execvy <at> gmail.com, 74813 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Date: Fri, 10 Jan 2025 16:04:47 +0800
> >> From: execvy <at> gmail.com
> >>
> >> My auto-repeat rate is 100 times/second
> >
> > Mine is 30/sec.  Maybe this is the reason for what you see.
> > Programmatically, M-v needs to do more than C-v does, so if your CPU
> > is not powerful enough, maybe Emacs cannot keep up with 100 keys per
> > second moving back.
> >
> > If this is the reason, then it's expected.
> >
> >> It's hard to notice performance difference by eyes and hands.
> >> You can do profiler-start (cpu) and profiler-report, then you will notice
> >> the profiler result is totally different.
> >
> > The profiler result is expected to be different, because M-v invokes
> > different functions than C-v does.
> >
> > What I measured is the total time of scrolling through the entire
> > file, and I didn't see any difference, as reported: 35 sec both down
> > and up.  I measured the time with a stopper, not by eyes.
> 
> It sounds like this is just the expected behavior here.  So I guess we
> should just close this?

Yes, done.

Previous Next

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