Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL

[GRAHAM ASHER]

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