Subject: bug#15390: 24.3; scrolling in emacs,w32 uses 100% cpu

From: Zack Stackson <[email-masked]>
Date: Mon, 23 Sep 2013 00:32:48 -0500

On Thu, Sep 19, 2013 at 2:51 AM, Eli Zaretskii <[email-masked]> wrote:
> Or are you are saying that the performance problems are only
> significant in a full-screen frame, and are imperceptible in the frame
> of the size created by "emacs -Q"?  In that case, let's talk _only_
> about maximized frames.

The slowness is not noticeable at the default frame size, although
even at the default frame size Emacs 24 uses much more cpu to page up
than Emacs 22.

>> They did not have any empty lines, adding empty lines made it much faster.
>
> "Much faster" as in "like Emacs 23", or even faster than that?  I
> would not expect the latter.

Much faster than when there were no empty lines, but still not nearly as
fast as Emacs 22.

>> Tried (setq bidi-paragraph-direction 'left-to-right) and (setq-default
>> bidi-paragraph-direction 'left-to-right), but that did not make it
>> faster.
>
> Did you try this before or after adding empty lines?  The effect
> should be significant only if there are no empty lines.

Tried both.

>> Emacs 23 is also slow, not as slow as 24, but not much different.
>> Emacs 22 is very fast, so that's the version I have been using.
>
> Emacs 23 started using the Uniscribe font back-end.  So please try
> this:
>
>   emacs -Q -xrm Emacs.fontBackend:gdi
>
> and see if it is much faster with the same frame geometry and font
> settings, in Emacs 24.

After starting with this, how do I tell if the -xrm option is in effect?

I don't see any speed difference.

>> Page up is also slow when editing files with syntax highlighting
>> (replace.el for example).
>
> Is it slow only the first time some screen-full is displayed?  That
> is, if you visit a file, page down several times through it, then go
> back to the beginning with C-Home, and page down again through the
> same portions of the file, is the second scroll also slow, or is it
> much faster?  If the latter, this is normal, as Emacs fontifies the
> text on the fly when it is first displayed, and that takes time.

It's about the same the first time and repeated times.

The problem is worst when starting at the end of the file and doing
page up from there, even after visiting the entire file and starting
over at the end, page up starting at the end causes rendering to stop
until beginning of file is reached or I stop holding the page up key
and wait.