bug#14721: slow scrolling on windows 7

[Mario Valencia]

I would say it's still a bug. And scrolling up, with PgUp is much slower than scrolling down. I have to set the keyboard repeat rate unacceptably low in order to be able to scroll normally with PgUp.

2013/6/26 Mario Valencia <mariovalspi@gmail.com>

I don't have the sources, but emacs can never keep up when I press PgDn or PgUp in any file in any mode. This always happened to me with emacs, maybe since the version that was released say a year ago for windows; I dont remember what version exactly. I can confirm this bug happens in fundamental mode, with emacs -Q, with a large text file that has no large lines.

I have an Acer Aspire One AOD257.
Intel(R) Atom(TM) CPU N570   @ 1.66GHz, 1666 Mhz

Not sure about the display.

Oh! I dont know how to see the exact number, but the keyboard repeat rate was set to max. I lowered it down and it solved the problem. Is it still a bug?

2013/6/26 Eli Zaretskii <eliz@gnu.org>

> Date: Wed, 26 Jun 2013 18:28:46 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 14721@debbugs.gnu.org

>
> [Please keep the bug address on the CC list, so this whole discussion
> is archived by the bug tracker.]
>
> > Date: Tue, 25 Jun 2013 22:42:59 -0500
> > From: Mario Valencia <mariovalspi@gmail.com>
> >
> > Yes, in any file.
> >
> > Yes, in any mode.
> >
> > Yes, with emacs -Q, as I said. It scrolls fine with the scroll bar though,
> > as well as with "emacs -nw".
>
> What CPU do you have there, and what display?
>
> Also, can you tell what is the frequency of the keyboard auto-repeat
> rate on that machine?
>
> In which version of Emacs did this start happening?
>
> (FWIW, I see no such slowdown on the Windows systems I work on.)

Here's an experiment; let me know what you see on your machine.

 emacs -Q
 C-x C-f xdisp.c RET
 M-x fundamental-mode RET

(Use any other large file if you don't have Emacs sources, which is
where xdisp.c comes from.)

Now lean on the PgDn key, and tell me whether Emacs can keep up.

On my Core i7 machine, Emacs keeps up just fine, and on average a
single processing unit is busy 20%, i.e. there's plenty of spare
processing power left.