Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL

[Алексей Подтележников]

Please confirm that ONE_PIXEL defined as  256 is not the unit of one pixel.
What is ONE_PIXEL then?

2010/10/13 GRAHAM ASHER <address@hidden>:
> 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
>
>



-- 
Alexei A. Podtelezhnikov, PhD