Re: Distinct performance issues with Japanese only on win32 systems

["David E. Hollingsworth" <deh curl com>]

Tor Lillqvist <tml iki fi> writes:

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

It's proportional to the length.  The real test is the C code I
referred to in the previous message.  The gedit "test" was just to
validate that the issue wasn't particular to my C code.


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

It turns out that reitemizing the items is not the primary issue.  I
now have some test code that runs as low as 40ms (110ms typical) when
used outside the pango environment but takes roughly 2s when called
from basic_engine_shape().  I don't have an explanation for this yet,
but I suspect it has something to do with state set on the HDC at the
time.  My goal is to create a patch and I'll report back if I get
stuck.


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

This does work, and for my sample Japanese texts the generated glyphs
are identical.  But my hypothesis (that the issue was related to
Japanese's use of multiple scripts) is busted: the same problem shows
up with Thai, which is definitely a complex script and requires the
use of Uniscribe.  So this would be a CJK hack and the general problem
would remain.

-- 
"I've just found the silverware and I'm sticking a fork in that square!" - N.H.