GNU bug report logs - #15390
24.3; scrolling in emacs,w32 uses 100% cpu

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Zack Stackson <zack.stackson <at> gmail.com>
Cc: 15390 <at> debbugs.gnu.org
Subject: bug#15390: 24.3; scrolling in emacs,w32 uses 100% cpu
Date: Mon, 23 Sep 2013 10:07:06 +0300

> Date: Mon, 23 Sep 2013 00:32:48 -0500
> From: Zack Stackson <zack.stackson <at> gmail.com>
> Cc: 15390 <at> debbugs.gnu.org
> 
> On Thu, Sep 19, 2013 at 2:51 AM, Eli Zaretskii <eliz <at> gnu.org> 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.

I explained why CPU usage is higher ion Emacs 24: it does more work
during redisplay to support advanced features.

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

It is in effect all the time in that session.

> I don't see any speed difference.

Then the font back-end is not a factor in this.

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

Scrolling back is always more CPU-intensive than scrolling forward,
due to the peculiarities of the Emacs display engine implementation.

Anyway, I don't see what else I can do with this bug report.
Scrolling very large windows one line at a time is expensive, but I
cannot see such a disastrous slowdown on my machine, which is very
similar to yours.  There's some work in the development code to speed
up redisplay, maybe it will improve your experience (perhaps try the
latest development snapshot).

Sorry.

Previous Next

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