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: Алексей Подтележников <apodt...@gmail.com> To: freetype-devel <freetype-devel@nongnu.org> 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 Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel