Re: Distinct performance issues with Japanese only on win32 systems

It seems Pango uses the Uniscribe script cache in a sub optimal way.
Pango always create new script caches and throws them away in each
call to uniscribe_shape.
But in the Uniscribe docs it does not say that the cache needs to be
cleared between ScriptItemize calls.

We did some experiments and made the script cache array static so it's
only initialized once and reused in each call.
This seems to solve the speed problem (generates a magnitude speedup).
Note:  I've checked and Arabic (complex script shaping) renders
correctly as far as I can see.

I've attached a crude patch (Pango version 1.16.2) with this change.
Note: this patch probably "leaks" a bit of memory as the pango
uniscribe shape caches are never freed. We need to find out if this is
a problem and how it could be solved.

Also it does not seem that this performance issue is isolated to
Japanese but for other scripts that need uniscribe as well.
I think Japanese however suffers more severely as it uses space
separators between the characters and that causes shape fragmentation
and thus will generate a lot more calls to "uniscribe_shape". This
will in turn make the caches quite useless.

Some other observations made:
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).

Also the array holding the script caches in Pango is static and set to
100 and it's indexed on script. However eScript datatype is a Opaque
10bit value.
It seems to been working well so far in Pango but could this be a
issue if MS changes the implementation and use values >99?



On Thu, Sep 10, 2009 at 5:14 PM, David E Hollingsworth
<deh fastanimals com> wrote:
> My apologies for not running gtk-demo to check before offering the patch!
> I'm not going to be able to look into it more for a while, so reverting may
> be the right choice at this time.
> David E Hollingsworth
> _______________________________________________
> gtk-i18n-list mailing list
> gtk-i18n-list gnome org

Attachment: basic-win32.c.patch
Description: Binary data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]