[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] scale F_dot_P down
From: |
Werner LEMBERG |
Subject: |
Re: [ft-devel] scale F_dot_P down |
Date: |
Fri, 07 Dec 2012 08:15:30 +0100 (CET) |
> ttinterp.c:2706: After checking if F_dot_P is smaller than a
> threshold, it is assigned a maximum possible value rather than a
> threshold value. Is it possible that there is one zero too many on
> line 2706 and we meant to assign a threshold value?
I think the current code is correct: If the value gets too small, use
a (possibly large) default value which essentially disables the
transformation.
> ttobjs.c:767: F_dot_P seems to be initialized to a tiny tiny value
> that is actually much smaller than the above threshold. It looks
> arbitrary when compared to the rest of F_dot_P usage instances with
> huge unscaled F_dot_P. Please check.
As far as I can see, this initialization is not necessary at all,
since F_dot_P gets always computed in line 8149 before any bytecode is
run. Perhaps a compiler has complained about a missing
initialization, and an arbitrary value (without a deeper look at the
code) has been assigned in line 767.
> 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.
(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.
Werner