On Fri, May 24, 2019 at 10:17 AM Behdad Esfahbod <beh...@behdad.org> 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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
