Re: [ft-devel] Pixel Differences after 2ea511eed8 and 7a81b63abc2b3

[Alexei Podtelezhnikov]

On Fri, May 24, 2019 at 10:17 AM Behdad Esfahbod <address@hidden> wrote:
> Alexei,
>
> I don't know about others on the list.  But I find the linear algebra / 
> bezier discussion very interesting and I'm happy to discuss those.
>
> The new algorithm is pretty simple, yes.  BTW, I wonder if the 1/8th of pixel 
> tolerance is what's causing this:
>
>   https://lists.cairographics.org/archives/cairo/2008-May/014149.html

In 2008, the flattening was 2 generations back... I doubt that 26.6
precision in scaling is insufficient for rendering, unless there was
an error. The descrete flattening could have played a role.

> 1/8th of a pixel sounds too large of an error for a 256-level rasterizer.

Microsoft uses 8 levels of gray, I think. Hence 1/8 seems reasonable.
It is a bit more complex. We consider individual x- and y- components,
so the distance could be sqrt(2)x larger when the segment is diagonal.
However, the curve itself is 0.5x or 0.75x closer in conic and cubic
cases respectively. As it currently stands,
- conic control-to-chord-centre components are limited to 1/8px, and
curve deviates by 0.09px in the worst diagonal case.
- cubic control-to-chord-trisection components are limited to 1/6px,
and curve deviates by 0.18px in the worst diagonal case.
It has been like this since 2011 or so. The conic case was tightened
when people complained https://savannah.nongnu.org/bugs/?32671. Nobody
complained about the cubic case, but we can align at some performance
cost.

One other though I have about flattening: going though on-points is
not optimal. A closer and quite simple trace is through the middles
between on and control points...

Regards,
Alexei