GNU bug report logs - #14721
slow scrolling on windows 7

Previous Next

Full log

Message #29 received at 14721 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mario Valencia <mariovalspi <at> gmail.com>
Cc: 14721 <at> debbugs.gnu.org
Subject: Re: bug#14721: slow scrolling on windows 7
Date: Fri, 28 Jun 2013 08:54:58 +0300

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

> Date: Thu, 27 Jun 2013 17:55:15 -0500
> From: Mario Valencia <mariovalspi <at> 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.

Previous Next

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