Re: [ft-devel] scale F_dot_P down

[Alexei Podtelezhnikov]

>> About the patch, whenever we use F_dot_P in the bytecode interpreter
>> in comparisons or divisions we have to scale up the other side by
>> 0x10000L.  I propose that instead we scale F_dot_P down by 0x10000L
>> when we assign it.  This improves readability and avoids huge
>> numbers and confusions with number of zeros.  Please review the
>> attached patch.
>
> I think it's better to not apply this patch.  Reasons:
>
>   (1) You are stripping off 16 bits of F_dot_P's precision.  Or am I
>       missing something?  Pixel positioning in the TT interpreter is
>       extremely sensitive to rounding; even smallest changes in the
>       code might cause pixel shifts.  Maybe such fixes/changes can be
>       played with after we have a test suite which does a lot of pixel
>       comparisons, but right now we don't have one.

Actually, we are stripping off only 14 bits. More to the point,
F_dot_P is used exclusively as a denominator to freeVector components,
which has 16-bit (F2Dot14) precision. Therefore, the division result
also has only 16 significant bits. The extra precision in F_dot_P is
essentially wasted. F_dot_P is calculated from 16-bit vectors, so
itself it only has 16 significant bits too. Those vectors are unit
vectors only within that precision. So I do not think we lose any
precision.

>   (2) FT_MulDiv and friends can handle 64bit precision internally, so
>       I don't see a problem here with large numbers.  And there is the
>       abovementioned check in line 2706 to avoid too small values
>       which would make the division overflow.

Yes, but 64-bit code path is very expensive and FT_MulFix tries hard
to avoid it when the arguments are small because it saves a lot of
time. Here we are handed over a 16 bit vector but scale it up so that
FT_MulFix has less chance to avoid the 64-bit code path. We are
actively hurting the performance for dubious precision reasons.

I am now more convinced that the patch is worth applying. It is not
just a code beautification but actual performance optimization.

Alexei