I'll try to find time - I suppose if I criticise I am obliged to ;-) But I am rather busy and it'll be difficult. And I don't really agree with your statement that:
"It is undeniable that it is so much better to have the same algorithm in both conic and cubic splines long term." The cases are different and demand different algorithms. In particular, cubic splines can be S-shaped - that is, the curve is on both sides of the chord - leading to the use of different, and much more complicated, methods for approximating the maximum distance of the curve from the chord. I agree that the minimum distance should be the same for both pieces of code. Graham ----- Original Message ---- From: Алексей Подтележников <apodt...@gmail.com> To: GRAHAM ASHER <graham.as...@btinternet.com> Cc: freetype-devel <freetype-devel@nongnu.org> Sent: Monday, 18 October, 2010 13:11:53 Subject: Re: [ft-devel] harmonize conic and cubic splines Graham, Let's work on ironing out the wrinkles and fine tuning ONE_PIXEL fraction, so that the code works best for freetype's purposes as well as yours. It is undeniable that it is so much better to have the same algorithm in both conic and cubic splines long term. Alexei 2010/10/18 GRAHAM ASHER <graham.as...@btinternet.com>: > I am sorry to say that I regard a 3% slowdown as intolerable, especially for my > purposes. I haven't noticed any quality problems with the existing code. We can > define quality as the inverse of the maximum distance of the generated line > segments from the actual curve; that can be adjusted using the existing > algorithm, in any case. The aim of code improvement in this area is to improve > speed while preserving quality. > > Graham > > > > > ----- Original Message ---- > From: Алексей Подтележников <apodt...@gmail.com> > To: freetype-devel <freetype-devel@nongnu.org> > Sent: Monday, 18 October, 2010 4:37:52 > Subject: [ft-devel] harmonize conic and cubic splines > > Werner, > > This patch harmonizes the algorithms that are used for flattening > conic and cubic splines. > It changes the conic ones to follow the same (more correct) procedure > as cubic ones. > The result, I think, is a better code and a slight improvement in > quality. You may see about > 3% slow-down, but this can be ironed out. > > Alexei > > -- Alexei A. Podtelezhnikov, PhD _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
