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 >
Attachment:
basic-win32.c.patch
Description: Binary data