all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jason Rumney <jasonr@gnu.org>
To: 233@emacsbugs.donarmstrong.com
Subject: bug#233: Analysis of redisplay performance on Windows
Date: Fri, 25 Jul 2008 01:22:28 +0100	[thread overview]
Message-ID: <48891CC4.4030508@gnu.org> (raw)

The redisplay performance problems on Windows seem to be mostly caused
by the left_overwriting and right_overwriting functions. These functions
analyse all glyphs, one by one, before and after (respectively) the
current glyph string on the same row to see if the glyphs overlap the
current glyph string.

To determine the overlap for each glyph, it is necessary to encode it
into a glyph code point in the font used to display it, then measure its
text extents.  Even with caching of the text extents, the Windows code
is still especially slow here because of the encoding to glyph code points.

Currently we cache glyph code points at the glyph_string level. Perhaps
caching them at the glyph row level would help, as we could then reuse
them after we have finished with the glyph string. Alternatively we
could keep all the glyph strings for the row until we are finished so we
could use glyph code points and other information from there. This might
reduce the number of iterations we need to find the left and right
overwriting glyphs, since we can check the glyph strings for overlaps
first, and only check the glyphs inside glyph strings that overlap.

There may also be a problem with the setting of
row->contains_overlapping_glyphs_p on Windows. The above functions
should only be called when that is set, but after inserting debugging
code I can see them being called frequently even when using fonts that
contain no overlapping glyphs (confirmed by further debugging code in
w32font_text_metrics).






             reply	other threads:[~2008-07-25  0:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-25  0:22 Jason Rumney [this message]
2008-07-25  0:52 ` bug#233: Analysis of redisplay performance on Windows Lennart Borgman (gmail)

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=48891CC4.4030508@gnu.org \
    --to=jasonr@gnu.org \
    --cc=233@emacsbugs.donarmstrong.com \
    /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.