I'm happy either way, as long as we keep seeing a similar performance
improvement. For now, I think I'll post a FT fork on GitHub that uses FPU math
and recommend compiling libass against that, and then I can get rid of it once
the stroker improvements have been made. Sound good?
On Tue, May 27, 2014 at 9:18 AM, Alexei Podtelezhnikov <[email protected]>
wrote:
> Hi Rodger,
> Your tests show that Freetype stroker relies on
> On Sat, May 24, 2014 at 12:49 AM, Rodger Combs <[email protected]>wrote:
>> While profiling libass in OSX's Instruments.app, I've found that
>> Freetype's stroker tends to come up as a very time-consuming routine, and
>> that most of the time spent in the stroker is in the trigonometry routines;
>> specifically, the atan2 and cosine functions seem rather slow.
>>
> You have shown that Freetype's stroker makes too many calls to
> trigonometric functions. This is true. It could be reimplemented with no
> trigonometric calls at all. We used to have emboldener rely on trigonometry
> too much; now it does not make a single trigonometric call. I meant to
> start working on it but life set different priorities. Some day I'll merge
> both features.
>> While it most likely makes sense to leave the current fixed-point
>> trigonometry in place for the sake of systems with slow (or no) FPU, it
>> seems apparent to me that floating-point versions should be used when
>> compiling for modern processors.
>>
> Trigonometry is used very sparsely in Freetype, except in the stroker. I
> dare you to find a different benchmark to show that trigonometry is a drag
> somewhere else. So I still prefer fixing the stroker to changing Freetype
> to use the FPU trigonometry.
> Best,
> Alexei
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
