freetype
[Top][All Lists]
Advanced

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

Re: [ft] Optimizing ft_adobe_glyph_list


From: Povilas Kanapickas
Subject: Re: [ft] Optimizing ft_adobe_glyph_list
Date: Sat, 13 Oct 2018 08:43:51 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 13/10/2018 08:32, Werner LEMBERG wrote:
> 
>>> [...], please outline with a few words how you are going to
>>> implement the compression.
>>
>> The size reduction is a result of several optimizations: [...]
> 
> Looks good, thanks.  I assume that this will be a modification to the
> existing `glnames.py' script, right?  Please ensure that the test
> function also works :-)

Yes, I'll modify the glnames.py script and regenerate the pstables.h
header. Will test everything for sure :-)

As a side note, would it be OK to:

 (a) modify the glnames script to use python3? python 2.x will be EOL soon.

 (b) use the standard python style as outlined in PEP 8? This will allow
to use tools like pylint and flake8 easily to catch stupid errors before
running the script.

If you agree, the patches for either or both of the above could come
before the changes to the algorithm itself.

>> All of the above increase the complexity and size of the retrieval
>> function.  Unfortunately we can't know the impact of the changes
>> until basically everything is finished and we do tests.  Maybe the
>> slowdown will be so severe that the proposal does not make sense :-)
> 
> It would be nice if you could provide some C code (using the FreeType
> API to access a standard, free font like DejaVu) that other people can
> then use for profiling.

My plan was to add micro-benchmarks that test the performance of the
code directly under different conditions (e.g. 100, 50, 0 percent of the
cache is cold before the calls). I can add a higher-level test too.
Should I commit the font file to the repository itself too?

Regards,
Povilas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]