freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] fttrigon: Use standard floating-point functions for perfo


From: Rodger Combs
Subject: Re: [ft-devel] fttrigon: Use standard floating-point functions for performance?
Date: Tue, 27 May 2014 07:45:45 -0700 (PDT)

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 <address@hidden> wrote:

Hi Rodger,

Your tests show that Freetype stroker relies on


On Sat, May 24, 2014 at 12:49 AM, Rodger Combs <address@hidden> 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



reply via email to

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