[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Devel] Smooth rasterizer gives inconsistent results for different
From: |
David Turner |
Subject: |
Re: [Devel] Smooth rasterizer gives inconsistent results for different fill rules |
Date: |
Wed, 17 Oct 2001 16:30:59 +0200 |
Hi Graham,
Graham Asher a écrit :
>
> I have recently created by own version of the smooth rasterizer using the
> code in ftgrays.c. I have not changed the algorithm in any way at all, so I
> *think* that the following comment applies to FreeType2 as well as to my
> code, and I'd be grateful for an explanation:
>
> If I create an outline made of a (rough) circle inside another circle, both
> clockwise, using conic splines, and rasterize it using even-odd fill, I get
> very slightly different weights for some of the pixels, compared to what I
> get if I make the inner circle anticlockwise and use the non-zero winding
> rule. Specifically, I get weights on the pixels intersecting the inner
> circle that are one greater when I use the non-zero winding rule: 0xE4, not
> 0xE3, for example.
>
> This probably doesn't matter, and it has all the distingishing marks of an
> inconsistency in rounding direction, but I would like to know if it is
> intentional. I think that a rasterizer that describes itself as 'perfect'
> (comment at the top of ftgrays.c: 'A new `perfect' anti-aliasing renderer')
> should be at least consistent ;-) In theory the two ways of defining a shape
> are equivalent and should yield the same results.
>
It is not intentional. The problem very likely comes from rounding "errors"
and one way to fix it would be to re-organize the outline parser to let it
process each glyph element (line segment or bezier arc) in exactly the same
way, independently of orientation
The "perfect" statement comes from the fact that the algorithm is capable
of retrieving the "exact" pixel coverage by analytic computation, instead
of performing performance-heavy bit-counting of kernel filtering..
> I can provide the data - points and resulting bitmaps - if necessary.
>
I don't have the time currently to look at it, and I don't think it's
too important. If you have a patch of some sort to "fix" this minor
issue, I'll gladly accept. Otherwise, they're simply much better things
to do right now, sorry...
Cheers,
- David