[ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL cont'd
Werner, Graham
It turns out that since 2.4.3 the cubic deviations have been estimated
*after* UPSCALE, whereas conic ones have been evaluated *before*
UPSCALE. This was probably the original sin that led to the misuse of
FT_MAX_CURVE_DEVIATION that we've just fixed in cubic.
Let's fix the original sin now.
Frankly, I would just adapt the cubic approach to conic splines too.
The current conic approach is just not very good... This will come a
little later.
diff --git a/src/smooth/ftgrays.c b/src/smooth/ftgrays.c
index 4477638..8f93392 100644
--- a/src/smooth/ftgrays.c
+++ b/src/smooth/ftgrays.c
@@ -877,40 +877,35 @@ typedef ptrdiff_t FT_PtrDist;
FT_Vector* arc;
- dx = DOWNSCALE( ras.x ) + to-x - ( control-x 1 );
- if ( dx 0 )
- dx = -dx;
- dy = DOWNSCALE( ras.y ) + to-y - ( control-y 1 );
- if ( dy 0 )
- dy = -dy;
+ arc = ras.bez_stack;
+ arc[0].x = UPSCALE( to-x );
+ arc[0].y = UPSCALE( to-y );
+ arc[1].x = UPSCALE( control-x );
+ arc[1].y = UPSCALE( control-y );
+ arc[2].x = ras.x;
+ arc[2].y = ras.y;
+
+ dx = FT_ABS( arc[2].x + arc[0].x - 2 * arc[1].x );
+ dy = FT_ABS( arc[2].y + arc[0].y - 2 * arc[1].y );
if ( dx dy )
dx = dy;
- if ( dx = ONE_PIXEL / 8 )
+ if ( dx = ONE_PIXEL / 4 )
{
- gray_render_line( RAS_VAR_ UPSCALE( to-x ), UPSCALE( to-y ) );
+ gray_render_line( RAS_VAR_ arc[0].x, arc[0].y );
return;
}
- level = 1;
- dx /= ONE_PIXEL / 8;
- while ( dx 1 )
+ level = 0;
+ while ( dx ONE_PIXEL / 4 )
{
dx = 2;
level++;
}
- arc = ras.bez_stack;
levels = ras.lev_stack;
- top = 0;
levels[0] = level;
-
- arc[0].x = UPSCALE( to-x );
- arc[0].y = UPSCALE( to-y );
- arc[1].x = UPSCALE( control-x );
- arc[1].y = UPSCALE( control-y );
- arc[2].x = ras.x;
- arc[2].y = ras.y;
+ top = 0;
while ( top = 0 )
{
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
ONE_PIXEL / 8 looks good! I hope everyone agrees that 244_8.png is not worse than 243_16.png. See attachments. Patch applied, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
Alexei,
Since there are two changes, (the value of FT_MAX_CURVE_DEVIATION and the
algorithm), each must be tested independently.
Which has broken the rendering?
We need trace info: Does the new algorithm actually do what it claims. I.e. is
the actual deviation really limited to the FT_MAX_CURVE_DEVIATION value, or has
the code change broken this?
I've attached a(n old) version of the trace code I used. It'll probably need
some modifying, but it includes what is required to calculate the *actual*
maximum deviation.
David %^
-Original Message-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
??? ?
Sent: 14 October 2010 02:03
To: Werner LEMBERG
Cc: freetype-devel@nongnu.org
Subject: Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
Hi all,
On Wed, Oct 13, 2010 at 9:41 AM, Werner LEMBERG w...@gnu.org wrote:
I guess my version has PIXEL_BITS = 6. Sorry, didn't notice the
discrepancy. Yes, FT_MAX_CURVE_DEVIATIO ought to be defined so that
it's always 1/4 of a pixel.
Alexej, can you provide a patch to fix that?
The patch is below. As was intended in the original code, it aims at the
max
deviation of ONE_PIXEL / 4. Remember that the original code actually used
ONE_PIXEL / 16. The speed-up is nice:
ftbench -b c -s 36 /usr/share/fonts/default/Type1/p052003l.pfb
Render: 29.216 us/op (before, see 243.png)
Render: 25.480 us/op (after, see 244.png)
Frankly, I think I am starting to notice the quality down a bit.
Please judge for yourself.
One quater is probably too close to the size of subpixels, so I
would consider
ONE_PIXEL / 8 instead. Would I make it tunable? No way, I don't want
people
to ever curse at freetype because someone misjudged his eyesight. It's too
subjective for one person to decide.
diff --git a/src/smooth/ftgrays.c b/src/smooth/ftgrays.c
index 17d172f..4828013 100644
--- a/src/smooth/ftgrays.c
+++ b/src/smooth/ftgrays.c
@@ -91,11 +91,6 @@
#define FT_COMPONENT trace_smooth
- /* The maximum distance of a curve from the chord, in 64ths of a pixel;
*/
- /* used when flattening curves.
*/
-#define FT_MAX_CURVE_DEVIATION 16
-
-
#ifdef _STANDALONE_
@@ -891,14 +886,14 @@ typedef ptrdiff_t FT_PtrDist;
if ( dx dy )
dx = dy;
-if ( dx = FT_MAX_CURVE_DEVIATION )
+if ( dx = ONE_PIXEL / 4 )
{
gray_render_line( RAS_VAR_ UPSCALE( to-x ), UPSCALE( to-y ) );
return;
}
level = 1;
-dx /= FT_MAX_CURVE_DEVIATION;
+dx /= ONE_PIXEL / 4;
while ( dx 1 )
{
dx = 2;
@@ -1074,7 +1069,7 @@ typedef ptrdiff_t FT_PtrDist;
goto Split;
/* Max deviation may be as much as (s/L) * 3/4 (if Hain's v = 1).
*/
-s_limit = L * (TPos)( FT_MAX_CURVE_DEVIATION / 0.75 );
+s_limit = L * (TPos)( ONE_PIXEL / 3 );
/* s is L * the perpendicular distance from P1 to the line P0-P3.
*/
dx1 = arc[1].x - arc[0].x;
#define TRACE_CUBIC
#ifdef TRACE_CUBIC
#include math.h
#endif
#ifdef TRACE_CUBIC
/*/
/* */
/* Returns the one-dimensional position of the Bezier point with */
/* parametric value t and control point values s0 .. s3. */
/* */
static double bez_param(double s0, double s1, double s2, double s3, double t)
{
double u = 1 - t;
return u * u * u * s0
+ 3 * t * u * (u * s1 + t * s2)
+ t * t * t * s3;
}
/*/
/* */
/* Returns the unnormalised s-coordinate of the point p in the r-s */
/* coordinate system for the Bezier curve defined by the points */
/* arc[0..3].*/
/* */
static FT_Pos s_dist(FT_Vector* arc, FT_Vector* p)
{
return (arc[0].y - p-y) * (arc[3].x - arc[0].x)
- (arc[0].x - p-x) * (arc[3].y - arc[0].y);
}
/*/
/* */
/* Returns the distance between points p and q. */
/* */
static double dist(FT_Vector* p, FT_Vector* q)
{
FT_Pos dx = q-x - p-x;
FT_Pos dy = q-y - p-y;
return sqrt(dx * dx + dy * dy
Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
2010/10/14 David Bevan david.be...@pb.com:
Since there are two changes, (the value of FT_MAX_CURVE_DEVIATION and the
algorithm),
each must be tested independently.
David,
Focus please. This thread is about fixing deviations only by using ONE_PIXEL.
diff --git a/src/smooth/ftgrays.c b/src/smooth/ftgrays.c
index 17d172f..4828013 100644
--- a/src/smooth/ftgrays.c
+++ b/src/smooth/ftgrays.c
@@ -91,11 +91,6 @@
#define FT_COMPONENT trace_smooth
- /* The maximum distance of a curve from the chord, in 64ths of a pixel;
*/
- /* used when flattening curves.
*/
-#define FT_MAX_CURVE_DEVIATION 16
-
-
#ifdef _STANDALONE_
@@ -891,14 +886,14 @@ typedef ptrdiff_t FT_PtrDist;
if ( dx dy )
dx = dy;
- if ( dx = FT_MAX_CURVE_DEVIATION )
+ if ( dx = ONE_PIXEL / 4 )
{
gray_render_line( RAS_VAR_ UPSCALE( to-x ), UPSCALE( to-y ) );
return;
}
level = 1;
- dx /= FT_MAX_CURVE_DEVIATION;
+ dx /= ONE_PIXEL / 4;
while ( dx 1 )
{
dx = 2;
@@ -1074,7 +1069,7 @@ typedef ptrdiff_t FT_PtrDist;
goto Split;
/* Max deviation may be as much as (s/L) * 3/4 (if Hain's v = 1).
*/
- s_limit = L * (TPos)( FT_MAX_CURVE_DEVIATION / 0.75 );
+ s_limit = L * (TPos)( ONE_PIXEL / 3 );
/* s is L * the perpendicular distance from P1 to the line P0-P3.
*/
dx1 = arc[1].x - arc[0].x;
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
ONE_PIXEL / 8 looks good! I hope everyone agrees that 244_8.png is not worse than 243_16.png. See attachments. Thanks for testing. For me, it looks OK $(Q#|(B I can only notice difference if I magnify the images. If others agree, I'll check in this patch. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
АП == Алексей Подтележников apodt...@gmail.com writes: АП ONE_PIXEL / 8 looks good! I hope everyone agrees that 244_8.png is not worse АП than 243_16.png. See attachments. It looks fine to me. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
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 graham.as...@btinternet.com: 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 -- Alexei A. Podtelezhnikov, PhD ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
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: Алексей Подтележников 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
Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
I guess my version has PIXEL_BITS = 6. Sorry, didn't notice the discrepancy. Yes, FT_MAX_CURVE_DEVIATIO ought to be defined so that it's always 1/4 of a pixel. Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: GRAHAM ASHER graham.as...@btinternet.com Cc: freetype-devel freetype-devel@nongnu.org Sent: Wednesday, 13 October, 2010 13:14:42 Subject: 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 graham.as...@btinternet.com: 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 -- Alexei A. Podtelezhnikov, PhD ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
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: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] 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: Алексей Подтележников 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
I guess my version has PIXEL_BITS = 6. Sorry, didn't notice the discrepancy. Yes, FT_MAX_CURVE_DEVIATIO ought to be defined so that it's always 1/4 of a pixel. Alexej, can you provide a patch to fix that? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
АП == Алексей Подтележников apodt...@gmail.com writes: АП Frankly, I think I am starting to notice the quality down a bit. I agree; the second png is worse that the first. But only just a bit. You should try ONE_PIXEL/8 as you suggested. Or, if even ONE_PIXEL/8 proves unpleasant, perhaps a patch to fix the comment to say that it is one 16th of a pixel might be better? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
