[ft-devel] Re: important ftraster fix

[Werner LEMBERG]

>> It seems that we never can completely match the Windows results :-(
>> Reason is probably that the Windows rasterizer and bytecode
>> interpreter uses floating point arithmetic AFAIK.  Well...
>
> I'm pretty certain they don't use floating point. On the other hand,
> they probably use different bezier decomposition algorithms.  I
> remember that we already encountered one case where the difference
> became apparent because we decided not to fill a pixel while Windows
> did, and that the math showed that the corresponding pixel center
> was outside the bezier path, by a really tiny margin.

OK.

> That's the kind of thing to expect when writing an fixed-point
> implementation from a specification that doesn't enforce a specific
> way to make computations. I wouldn't be surprised if the various
> Windows renderers didn't change their algorithms several times
> too :-)

You mean exactly the opposite, BTW :-)

>> Are the values I've selected for `step' and `jitter' reasonable?
>> Can you give an explanation how the original values have been
>> determined?
>
> The original values have been determined empirically by no other
> than myself :-) Which means that if you have better values, go for
> them.  Can you just check with ftbench that this doesn't have a too
> important impact on rasterization performance at small sizes?

It doesn't seem to have a great impact:

verdana.ttf
  old:
    Render                    : 18.897 us/op
    Render                    : 23.796 us/op
    Render                    : 18.547 us/op
  new:
    Render                    : 21.347 us/op
    Render                    : 15.398 us/op
    Render                    : 18.423 us/op

tahoma.ttf
  old:
    Render                    : 25.923 us/op
    Render                    : 24.135 us/op
    Render                    : 26.817 us/op
  new:
    Render                    : 26.370 us/op
    Render                    : 27.711 us/op
    Render                    : 29.052 us/op

>> And finally: Do you see any problem with this change?  I could
>> imagine to introduce an `FT_OUTLINE_ULTRA_HIGH_PRECISION' for
>> resolutions lower than or equal to, say, 16ppem -- however, I think
>> this is probably unnecessary.
>
> I don't see a problem, as long as the extra precision is used for
> small sizes where it is very unlikely to get any overflows. the
> "ultra high precision" mode is probably too much I believe, unless
> there are some serious performance consequences in applying the
> patch.

OK.  Will apply then.


    Werner