RE: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL

[David Bevan]

Alexei,

Similarly, I don't have the time necessary to validate and performance-test 
your new algorithm.

Perhaps a good start would be for you to produce trace and performance results 
comparing your algorithm against what Graham checked in (as I did, for example, 
in my message of Tue, 7 Sep 2010 12:39:12 -0400).

I don't think that s and s_limit should be considered as areas. They are 
(strangely scaled) linear measurements. The only reason for the strange scaling 
is to improve speed.

Btw, your earlier comment about the overflow protection is correct. Removing it 
isn't acceptable though (since you're still squaring dx, etc.)

Regards,

David %^>


> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf Of
> GRAHAM ASHER
> Sent: 13 October 2010 09:45
> To: Алексей Подтележников; freetype-devel
> Subject: Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
> 
> Alexei,
> 
> I don't have much time or energy for this at the moment - sorry. Of course
> I
> will be looking at it again, but I believe that the solution hammered out
> by
> David Bevan and myself is a good one - it solves the bug I introduced
> while
> retaining the speed increases I first made the changes for.
> 
> Please note that the definition of FT_MAX_CURVE_DEVIATION as 16 gives a
> value of
> 1/4, not 1/16 as you suggest. This code works in units of 1/64 of a pixel.
> 
> Best regards,
> 
> Graham
> 
> 
> 
> ----- Original Message ----
> From: Алексей Подтележников <address@hidden>
> To: freetype-devel <address@hidden>
> Sent: Wednesday, 13 October, 2010 2:25:40
> Subject: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
> 
> Guys,
> 
> Currently smooth/ftgrays.c contains this:
> 
>   /* The maximum distance of a curve from the chord, in 64ths of a pixel;
> */
>   /* used when flattening curves.
> */
> #define FT_MAX_CURVE_DEVIATION  16
> 
> and this:
> 
>   /* must be at least 6 bits! */
> #define PIXEL_BITS  8
> 
> #define ONE_PIXEL       ( 1L << PIXEL_BITS )
> 
> Wouldn't that make sense to reconcile the two and
> possibly just use an explicit fraction of ONE_PIXEL instead?
> If I am not confused  FT_MAX_CURVE_DEVIATION could be replaced
> with a larger value. 16 / 256th is really very conservative and
> you still make too many splits.
> 
> Also, s and s_limit actually mean some sort of an area measure.
> It would make perfect sense to use TArea as type of these variables.
> 
> Finally, I have more "geometrical" suggestions, but I'll wait with the
> patch,
> until I hear back Re this and my previous message.
> 
> 
> Best,
> Alexei
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel
> 
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel