freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL


From: David Bevan
Subject: RE: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
Date: Thu, 14 Oct 2010 04:02:19 -0400

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: address@hidden
> [mailto:address@hidden On Behalf Of
> ??????? ?????????????
> Sent: 14 October 2010 02:03
> To: Werner LEMBERG
> Cc: address@hidden
> Subject: Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
> 
> Hi all,
> 
> On Wed, Oct 13, 2010 at 9:41 AM, Werner LEMBERG <address@hidden> 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;

Attachment: trace_cubic.c
Description: trace_cubic.c


reply via email to

[Prev in Thread] Current Thread [Next in Thread]