Re: Analysis of redisplay performance on Windows

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Mon, 28 Jul 2008 13:24:47 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>>>> On Sun, 27 Jul 2008 22:53:47 +0100, Jason Rumney <jasonr@gnu.org> said:
>> One difference between Emacs 22 and 23 is that we compute glyph
>> indexes properly in Emacs 23, while on 22 we use unicode code
>> points. Since we call font->encode_char once per character rather
>> than for a whole run, the overhead of selecting fonts into the GC
>> is multiplied.

> According to the document below, Uniscribe seems to provide some
> mechanism to defer heavy operations such as get_frame_dc and
> SelectObject.

>   http://www.microsoft.com/typography/developers/uniscribe/uniscribe.htm#SCRIPT_CACHE

The following document might be better.

  http://msdn.microsoft.com/en-us/library/ms776490.aspx

  Caching

  Uniscribe saves Unicode-to-glyph (cmap) mappings, glyph widths, and
  OpenType script shaping tables. A handle to the tables for a
  particular font of a particular size is called a "script
  cache". Many Uniscribe functions call for both an device context
  handle parameter and a SCRIPT_CACHE parameter. These functions look
  first for information through the script cache, using the device
  context only when required tables are not already cached.
  (snip)

  For ScriptShape and ScriptPlace, it is valid for the application to
  pass a null device context. Most often the call will succeed, as
  required tables are already cached. If the shaping or placement
  requires access to a device context, ScriptShape or ScriptPlace
  returns immediately with the E_PENDING error code. Then the
  application must select the font in the device context. For most
  applications, this helps performance by avoiding repeated
  preparation of a device context handle with calls to SelectObject.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp