all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: bogossian@mail.com
To: 6364@debbugs.gnu.org
Subject: bug#6364: Windows: Emacs 23 slow with long lines and raster fonts
Date: Sun, 06 Jun 2010 14:39:35 -0400	[thread overview]
Message-ID: <8CCD3BEBEE756DD-DB8-DFB9@web-mmc-m08.sysops.aol.com> (raw)

Hi,

the Windows build of Emacs 23 is extremely slow when scrolling in a 
buffer
containing long lines if a bitmap font is used.

For example, scrolling though a file made of 200 lines of 1000 
characters
each feels choppy.
Doing the same with a file containing very long lines (like tens of 
thousand
characters) can make Emacs hang for seconds or minutes, making it 
practically
unusable.

Editing files with such long lines is not absurd, various types of 
computer
generated files (log files, export files, dumps, ...) can have very very
long lines.

These bad performances are a regression, Emacs 21 and Emcas 22 were much
faster in the same conditions.

To illustrate this regression, and to show it's related to the use of 
bitmap
fonts, I've made this very simple and easy to reproduce benchmark:

I built an 8MB file containing a single line (the content of the file
doesn't matter). I opened the file in emacs, and then I hit "ESC >" to 
reach
the end of the buffer. I measured the time it takes for emacs to refresh
from the moment I typed the macro.

(Test setup: Athlon XP 2GHz, Windows XP SP3)

If Emacs is started with the command line "emacs -q", here are the 
results:

Emacs 21.3.1:    8s
Emacs 22.3.1:   14s
Emacs 23.2.1:   63s  (uniscribe backend)

Emacs 23 can be made a little faster by forcing the gdi rendering 
backend
with the command line "emacs -q -xrm Emacs.FontBackend:gdi":

Emacs 23.2.1:   38s  (gdi backend)

Now, if I repeat the same test using the command "emacs -q -fn 
Courier", to
use a bitmap font, things are getting really bad for Emacs 23:

Emacs 21.3.1:    8s  (raster font)
Emacs 22.3.1:   14s  (raster font)
Emacs 23.2.1:  515s  (raster font, gdi backend)

Regards,

Pierre

PS: this issue has been discussed on the emacs-devel mailing list:
http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00478.html





             reply	other threads:[~2010-06-06 18:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-06 18:39 bogossian [this message]
2013-11-26  0:35 ` bug#6364: [PATCH] Use GetCharABCWidthsFloatW if GetGlyphOutlineW fails Tom Seddon
2013-11-26 17:52   ` Eli Zaretskii
2013-11-26 19:39     ` Tom Seddon
2013-11-26 20:20       ` Eli Zaretskii
2013-11-26 20:30         ` Tom Seddon
2013-11-26 20:48           ` Eli Zaretskii
2013-11-26 21:50             ` Tom Seddon
2013-11-26 21:53               ` Tom Seddon
2013-11-29 11:05               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8CCD3BEBEE756DD-DB8-DFB9@web-mmc-m08.sysops.aol.com \
    --to=bogossian@mail.com \
    --cc=6364@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.