Re: Distinct performance issues with Japanese only on win32 systems

[Fredrik Corneliusson <fredrik corneliusson gmail com>]

I just saw that I mentioned the wrong Pango version, It's actually a
patch for Pango 1.26.2. not 1.16.2.
I would like to thank Dave E Hollingsworth for finding and working on
this issue in the first place.


On Thu, Apr 8, 2010 at 8:17 PM, Fredrik Corneliusson
<fredrik corneliusson gmail com> wrote:
> Hi,
> 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?
>
> References:
> http://msdn.microsoft.com/en-us/library/dd368797%28v=VS.85%29.aspx
> http://msdn.microsoft.com/en-us/library/dd317726%28v=VS.85%29.aspx
>
> Regards,
> Fredrik
>
> 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
>> http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>>
>