Re: anyone notice speed of 2.17.95 on Windows ?

[David Kastrup]

"Keith OHara" <address@hidden> writes:

> On Tue, 10 Dec 2013 17:22:19 -0800, David Kastrup <address@hidden> wrote:
>
>> "Keith OHara" <address@hidden> writes:
>>
>>> The last time we had a doubling of time required on Windows relative
>>> to Linux, issue 1926, it was repeated calls to find_by_name() that go
>>> through Pango to the font server.
>>>
>>> Here the outlines seem to be properly cached; it looks like each text
>>> glyph is looked up just one extra time.
>>
>> Once every time it is written, or once per document?  And what does
>> "just one extra time" mean?  One extra per which occasion?
>
> After a brief look at the code, it looked like for each glyph being
> laid out there is one extra call of Open_type_font:: or
> Pango_font::name_to_index(), which is the function called by
> find_by_name() that caused the extra time with issue 1926.
>
> That is, for every 'mf' in the piece, we look up two glyphs by name
> m' and 'f' from the font to get a skyline for the 'mf',

Do we really do that or is there one lookup for "mf"?  If it is the
latter, caching seems a bit troublesome.

> each skyline is built just once.  The look-ups are extra over those
> used to implement the stencil.
>
> One extra lookup per glyph might be enough to explain the difference.
> We need to look up the glyph to get a skyline, but maybe could cache
> its index into the font in the stencil.

That does not sound very useful since we still would do the lookup once
per stencil rather than once per m and once per f.

It _is_ annoying that this job is not done efficiently by the Freetype
library.

Is it possible that the Freetype library on Windows imprudently accesses
(and possibly creates on the fly) some Truetype versions or conversions
of the fonts for getting the outlines?

That might also explain
<URL:http://code.google.com/p/lilypond/issues/detail?id=2657>, the still
unresolved Issue 2657: font kerning on Windows is broken

> What did you mean to suggest here? :

>>>> Maybe caching in unsuitable form?  Cached data should be in a form
>>>> directly usable for processing (with some possible tradeoffs between
>>>> memory impact and unpacking speed), not in the form that
>>>> function/library/system calls will return it.

I was merely speculating that the form in which any existing caching
happened might be ill-chosen, not resulting in the winnings to be
expected from caching.

-- 
David Kastrup