Re: Distinct performance issues with Japanese only on win32 systems

I managed to *break* the rendering in my old patch by using many
different sizes so it's *not* useful.

But with help from Fredrik Estreen I managed to implement it the
correct way as you suggested.
The new patch attached uses a hash table keyed on font description and
script to get the script caches.
And the speedup seems to be the same as the old patch :-)
The only thing still missing is a freeing the caches on exit. However
I do not know how necessary that is.

I've also attached the pygtk test application I used to find the
rendering issue in the first patch and test the new.


On Fri, Apr 9, 2010 at 11:02 AM, Tor Lillqvist <tml iki fi> wrote:
>> 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
> _______________________________________________
> gtk-i18n-list mailing list
> gtk-i18n-list gnome org

Attachment: pango_win32_unuscribe_patch.diff
Description: Binary data

Description: Zip archive

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