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

[Eli Zaretskii]

> Date: Wed, 18 Sep 2013 22:53:36 -0500
> From: Zack Stackson <zack.stackson@gmail.com>
> Cc: 15390@debbugs.gnu.org
> 
> On Mon, Sep 16, 2013 at 1:41 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Mine is 1920x1080 (but I don't think the size matters here, unless you
> > are running with the frame maximized, which you didn't say).
> 
> I am running with frame height maximized (1440px), performance with
> height set to 720px is not nearly as bad.

Sorry, I don't understand what the last part means.  Is the 720 pixel
size what you get when you invoke Emacs as "emacs -Q"?  If not, please
let's first talk about what happens in the frame created by "emacs -Q"
and not enlarged by any command or mouse gestures.  That is what I did
to try reproducing your problems.

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.

> Also tested with emacs -Q and setting font to small size, page up
> slowness is the same.

I don't think the size of the font is a factor, as long as the frame
size changes accordingly.  What matters is the amount of text Emacs
needs to scan and move when scrolling.

> > Emacs 24's display performance is sensitive to the paragraph length as
> > well.  A paragraph start and end are defined for this purpose as empty
> > lines.  Is it possible that the text files you used didn't have any
> > empty lines at all?  If so, can you try files that do have empty
> > lines?  Also try setting bidi-paragraph-direction to left-to-right
> > (it's a per-buffer setting, so use setq-default to do that in all
> > buffers).
> 
> 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.

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

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

> Do bitmap raster fonts take more work than other fonts, maybe that's
> part of it?

I don't know enough about the Windows font back-ends and drawing APIs
to answer that, sorry.

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

> > In addition, the characters that begin a paragraph might be of
> > importance.  You say "text file", so I presume that is human-readable
> > text, but it could also be a file with many digits and punctuation
> > characters -- these make redisplay work harder.
> 
> Yes, there are many numbers and punctuation, just tested with the
> following repeated:
> 
> AA3036B2-CCCC DD3036E1-FFF Test text Test text Test text Test text Test

"A", the first character of the line, is not a numeric character, so
this is not an issue in your case.

> But it also happens on syntax highlighted files when using a small font.

Syntax highlighting introduces additional factors, see above.  So I
suggest for now to try only modes that don't highlight text, or even
turn off global-font-lock-mode entirely, when testing.