[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] scale F_dot_P down
From: |
Alexei Podtelezhnikov |
Subject: |
Re: [ft-devel] scale F_dot_P down |
Date: |
Fri, 7 Dec 2012 09:09:55 -0500 |
>> 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