bug#14721: slow scrolling on windows 7

bug#14721: slow scrolling on windows 7

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 2665 bytes --]

If i keep PageUp or PageDown pressed on a buffer, it does not redisplay the
screen fast enough. Only when I release the key, will it update the screen.
I have had this problem since previous versions of emacs on windows.
Scolling with the scroll bar works fine. I ran emacs with -Q. It also
scrolls fine if I run without graphical interface (-nw).

In GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
 of 2013-03-17 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

Important settings:
  value of $LANG: ESM
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<lwindow> <apps> M-x r e p o r t - e m a c s - b u
g <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win
w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32 multi-tty emacs)

[-- Attachment #2: Type: text/html, Size: 2957 bytes --]

bug#14721: slow scrolling on windows 7

[Eli Zaretskii]

> Date: Tue, 25 Jun 2013 21:38:36 -0500
> From: Mario Valencia <mariovalspi@gmail.com>
> 
> If i keep PageUp or PageDown pressed on a buffer, it does not redisplay the
> screen fast enough. Only when I release the key, will it update the screen.
> I have had this problem since previous versions of emacs on windows.

Does it happen with any file you visit, or just with some?

Does it happen in any major mode, or just with some?

Does this happen in "emacs -Q"?

bug#14721: slow scrolling on windows 7

[Eli Zaretskii]

[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.)

bug#14721: slow scrolling on windows 7

[Eli Zaretskii]

> 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.

bug#14721: slow scrolling on windows 7

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

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.
>

[-- Attachment #2: Type: text/html, Size: 2719 bytes --]

bug#14721: slow scrolling on windows 7

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]

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.
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3359 bytes --]

bug#14721: slow scrolling on windows 7

[Eli Zaretskii]

> Date: Wed, 26 Jun 2013 19:04:22 -0500
> From: Mario Valencia <mariovalspi@gmail.com>
> Cc: 14721@debbugs.gnu.org
> 
> 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.

I'd say this is expected with your CPU.  It's not a bug in the sense
that the code works as it was designed.  If someone knows how to make
scrolling much faster (I don't), patches are welcome.

bug#14721: Fwd: bug#14721: slow scrolling on windows 7

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

---------- Forwarded message ----------
From: Mario Valencia <mariovalspi@gmail.com>
Date: 2013/6/27
Subject: Re: bug#14721: slow scrolling on windows 7
To: Eli Zaretskii <eliz@gnu.org>


I don't know why scrolling has to be so slow. I certainly don't have that
problem with any other text editor. Moreover, it scrolls just fine with the
scroll bar. And why is scrolling up with PgUp much slower than scrolling
down?


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

> > Date: Wed, 26 Jun 2013 19:04:22 -0500
> > From: Mario Valencia <mariovalspi@gmail.com>
> > Cc: 14721@debbugs.gnu.org
> >
> > 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.
>
> I'd say this is expected with your CPU.  It's not a bug in the sense
> that the code works as it was designed.  If someone knows how to make
> scrolling much faster (I don't), patches are welcome.
>
>

[-- Attachment #2: Type: text/html, Size: 1800 bytes --]

bug#14721: slow scrolling on windows 7

[Eli Zaretskii]

[Please keep the bug address on the CC list.]

> Date: Thu, 27 Jun 2013 17:55:15 -0500
> From: Mario Valencia <mariovalspi@gmail.com>
> 
> I don't know why scrolling has to be so slow. I certainly don't have that
> problem with any other text editor.

Emacs have a lot of display-related features other editors don't,
which makes the simplest display-oriented operations very complex
under the hood.

Just to give you an idea of the complexity: when text includes
variable-size fonts and images, how do you know where is the start of
the next or previous window-full, in terms of character positions?
E.g., if the next/previous line beyond the current window is a large
image, scrolling would mean to move the viewport by a single line.  By
contrast, if you are in some kind of folding mode, which hides a lot
of text, the next/previous window start can be very far away.  There's
no way Emacs can know this in advance, so it actually scans the text
before and after the window to decide where to start the next
window-full.

> Moreover, it scrolls just fine with the scroll bar.

Scroll bar scrolls by smaller amounts, so Emacs succeeds to optimize
redisplay and keep up.

> And why is scrolling up with PgUp much slower than scrolling down?

For boring technical reasons, scrolling up and down use very different
code paths in the display engine.

bug#14721: slow scrolling on windows 7

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]

Well I guess that's it then, there's no way to fix it. :(


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

> [Please keep the bug address on the CC list.]
>
> > Date: Thu, 27 Jun 2013 17:55:15 -0500
> > From: Mario Valencia <mariovalspi@gmail.com>
> >
> > I don't know why scrolling has to be so slow. I certainly don't have that
> > problem with any other text editor.
>
> Emacs have a lot of display-related features other editors don't,
> which makes the simplest display-oriented operations very complex
> under the hood.
>
> Just to give you an idea of the complexity: when text includes
> variable-size fonts and images, how do you know where is the start of
> the next or previous window-full, in terms of character positions?
> E.g., if the next/previous line beyond the current window is a large
> image, scrolling would mean to move the viewport by a single line.  By
> contrast, if you are in some kind of folding mode, which hides a lot
> of text, the next/previous window start can be very far away.  There's
> no way Emacs can know this in advance, so it actually scans the text
> before and after the window to decide where to start the next
> window-full.
>
> > Moreover, it scrolls just fine with the scroll bar.
>
> Scroll bar scrolls by smaller amounts, so Emacs succeeds to optimize
> redisplay and keep up.
>
> > And why is scrolling up with PgUp much slower than scrolling down?
>
> For boring technical reasons, scrolling up and down use very different
> code paths in the display engine.
>

[-- Attachment #2: Type: text/html, Size: 2064 bytes --]

bug#14721: slow scrolling on windows 7

[Eli Zaretskii]

> Date: Fri, 28 Jun 2013 01:28:53 -0500
> From: Mario Valencia <mariovalspi@gmail.com>
> Cc: 14721@debbugs.gnu.org
> 
> Well I guess that's it then, there's no way to fix it. :(

Try a faster machine.

bug#14721: slow scrolling on windows 7

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

finally discovered that  emacs -xrm Emacs.fontBackend:gdi   makes scrolling
much faster.


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

> > Date: Fri, 28 Jun 2013 01:28:53 -0500
> > From: Mario Valencia <mariovalspi@gmail.com>
> > Cc: 14721@debbugs.gnu.org
> >
> > Well I guess that's it then, there's no way to fix it. :(
>
> Try a faster machine.
>

[-- Attachment #2: Type: text/html, Size: 800 bytes --]

bug#14721: slow scrolling on windows 7

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

and btw, my computer is NOT "too slow" to scroll fast. it is a bug for sure.


2013/9/11 Mario Valencia <mariovalspi@gmail.com>

> finally discovered that  emacs -xrm Emacs.fontBackend:gdi   makes
> scrolling much faster.
>
>
> 2013/6/28 Eli Zaretskii <eliz@gnu.org>
>
>> > Date: Fri, 28 Jun 2013 01:28:53 -0500
>> > From: Mario Valencia <mariovalspi@gmail.com>
>> > Cc: 14721@debbugs.gnu.org
>> >
>> > Well I guess that's it then, there's no way to fix it. :(
>>
>> Try a faster machine.
>>
>
>

[-- Attachment #2: Type: text/html, Size: 1315 bytes --]

bug#14721: slow scrolling on windows 7

[Eli Zaretskii]

> Date: Wed, 11 Sep 2013 21:26:36 -0500
> From: Mario Valencia <mariovalspi@gmail.com>
> Cc: 14721@debbugs.gnu.org
> 
> and btw, my computer is NOT "too slow" to scroll fast. it is a bug for sure.
> 
> > finally discovered that  emacs -xrm Emacs.fontBackend:gdi   makes
> > scrolling much faster.

If switching the font back end makes it much faster, then if there is
a bug, it's not in Emacs.  Emacs uses both font back ends the same.
Granted, the default Uniscribe back end is much more complex, so can
take more processing power (through I don't see any difference on my
machine).

bug#14721: slow scrolling on windows 7

[Eli Zaretskii]

> Date: Thu, 12 Sep 2013 05:47:34 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 14721@debbugs.gnu.org
> 
> If switching the font back end makes it much faster, then if there is
> a bug, it's not in Emacs.  Emacs uses both font back ends the same.
> Granted, the default Uniscribe back end is much more complex, so can
> take more processing power (through I don't see any difference on my
> machine).

Actually, there could be some difference due to a more complex
processing that the Uniscribe back end might induce on Emacs, but that
should only happen with complex scripts.  And you say that you see the
problem with any file, including, I presume, pure ASCII text.  So I
don't think complex script processing could be an issue here.