>> 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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
