Re: [ft-devel] scale F_dot_P down

[Werner LEMBERG]

> 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