Re: Distinct performance issues with Japanese only on win32 systems

[Tor Lillqvist <tml iki fi>]

> If you run gedit for win32 and load a moderate-length (120kB) Japanese
> document, it takes several seconds, whereas an English equivalent
> document is essentially instantaneous.

Hmm, is this the time it takes to process the entire document through
Pango? Or just one screenful? I,.e, is the time proportional to the
length of the document?

> Looking into the basic-win32 module, what's happening is that Pango
> appears to use -- when text_is_simple() returns false -- Uniscribe's
> full itemize-and-shape algorithm for each Pango item.

It's been a while since I wrote that code... Have you experience of
using Uniscribe? Do you think it would be possible to bypass the
Uniscribe itemization then assuming that Pango's itemization is "good
enough" for Uniscribe, too? Are you able to build Pango for Windows,
can you experiment and come up with a patch?

> I presume it
> does this because there's some case where Pango considers something a
> single item but Uniscribe breaks it into multiple items,

Setting the environment variable PANGO_WIN32_DEBUG will cause lots of
debugging output to be printed to stdout. From that it should be
possible to investigate what is going on, for instance whether
Uniscribe itemizes one Pango item further.

> But I haven't been able to figure out the benefit of using Uniscribe
> for most CJK texts.

It might be worthwhile then to explicitly check for a simple case of
just plain CJK characters and make text_is_simple() explicitly return
true in that case then?

--tml