freetype-devel
[Top][All Lists]
Advanced

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

[Devel] Error in new FT_SqrtFixed? [was: Summary of BBox computation iss


From: Tom Kacvinsky
Subject: [Devel] Error in new FT_SqrtFixed? [was: Summary of BBox computation issues]
Date: Thu, 26 Apr 2001 01:48:51 -0400 (EDT)

However, there seems to be an error with the new optimizations.  At least I am
not getting the correct results with the new FT_SqrtFixed.

On Thu, 26 Apr 2001, David Turner wrote:

> Hello,
>
>   I've just commited some minor improvements to "ftbbox.c" and
>   "ftcalc.c" and would like to sum up what I've found so far:
>
>   I. Regarding algorithm performance:
>
>     the direct computation seems to benefit greatly from the
>     optimisation of FT_SqrtFixed with an algorithm that doesn't
>     use multiplications.. (see "ftcalc.c")
>
>     Actually, for compilers with 64-bit integers, the direct
>     computation routines now seem to run as fast as the subdivision
>     one, or even slightly faster :-)
>
>     Without 64-bit integers, the slower FT_MulFix and FT_DivFix
>     slow the routine significantly (10% to 50% slower than the
>     subdivision routine, depending on the outline.)
>
>     The benchmark seems to show that computing a bbox is about
>     20 times slower than computing its cbox, when the boxes
>     differ.. even with the best algorithm !!
>
>
>   II. Regarding pixel-correct bbox computations:
>
>     After careful examination, it appears that the two
>     scanline-converters that come with FreeType do not use
>     the same accuracy when performing bezier arc splits:
>
>      - the monochrome raster uses 10 and 6 bits of precision
>        to express point coordinates, depending on the
>        "outline.high_precision" flag. bezier sub-division
>        is performed either through
>
>      - the anti-aliased raster uses 8 bits of precision, as
>        well as an adaptive bezier sub-division algorithm
>        based on the arc's dimensions..
>
>     it is thus not possible to compute pixel-exact computations
>     without using the exact-same subdivision algorithm.
>
>     This is considered too much trouble for too little benefit,
>     so let's forget about having pixel correct bboxes..
>
> As usual, any comment is welcomed..
>
> Cheers,
>
> - David
>
> _______________________________________________
> Devel mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/devel
>




reply via email to

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