Re: Distinct performance issues with Japanese only on win32 systems

[Tor Lillqvist <tml iki fi>]

> Yes this is related to Davids patch. It differs from that patch in
> that it keeps the separate caches for scripts and only makes them
> static.

Ah, yes. I replied in a hurry without actually having even looked at
your patch, sigh... It is quite minimal, I love that!

> Reading the uniscribe docs is seems that you should use a separate
> cache for every font+size combination. However in the pango code it
> just uses separate cache based on "script" (the
> SCRIPT_ANALYSIS.eScript) . I've tried to make it break by changing
> fonts and size used but I seems to work anyway which is strange (or I
> probably do not understand the code well enough).

I agree, that does sound a bit dangerouns. Maybe the code is working
"just by accident" and could break in some future Windows version.

Probably it should be changed to do it as you say, for instance
have a hash table of SCRIPT_CACHEs per (font,size,script) combination?
(That would also take care of the current dangerous assumption that
all eScript values are < 99.)

Or maybe the SCRIPT_CACHE contains identifying information and
Uniscribe is clever enough to just ignore a SCRIPT_CACHE if it notices
it is for the wrong (font,size,script) combination? But then David's
patch wouldn't have broken Arabic shaping, would it?

Sigh. I wish Microsoft's documentation was a bit clearer... For
SCRIPT_CACHE, they just say "The application must allocate and retain
one SCRIPT_CACHE variable for each character style used" but what does
"character style" mean, exactly?

--tml