Re: Distinct performance issues with Japanese only on win32 systems

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

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