Re: [ft-devel] cubic clean up
Shaded areas Before and After in the attached figures show where control points have should be to permit flattening. Is this a risky change? If anything, it is slightly more conservative, yet the conditional is quite a bit simpler. Uh, oh, I have no idea what you are talking about. Please provide more context, especially the formulae you are referring to. It would also help if you use lines to connect the control points in the image. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] cubic clean up
Aleksei, If you relax the condition, you increase the number of splits. Normally, making such a change is a mistake because the benefit of simplifying the condition is easily outweighed by the greater cost of increasing the recursive depth. This is the very reason why we ended up with a much more complex set of conditions than in earlier version of FT: it reduces the number of splits very significantly. I've just had a brief chance to look at your proposal, and I now understand why it makes no difference to the output. The chances of your relaxed condition causing a split when the current (theoretically correct) condition doesn't is very small: a control point would have to be in the small white areas in the bottom corners of the rectangle in your diagram. Note that this check is only made after subdivisions for the distance from the chord. Since this is the most expensive test, it is done last, and normally only once. Since there is no performance improvement, I don't believe that your proposal should be included in the code. It would make the code more opaque: It is obvious why the current code [if P1 or P2 is outside P0-P3, split the curve] does what it does (especially if reference is made to Hain's paper); it would not be at all clear why your condition for splitting [if P1 or P2 is far from the center of P0-P3, split the curve] was there. If you do come up with an improvement to the algorithm that is significantly faster (and still provably correct), then by all means submit it for review (but don't expect a quick or uncritical response). Thanks. David %^ -Original Message- From: freetype-devel-bounces+david.bevan=pb@nongnu.org [mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of ??? ? Sent: 11 November 2010 20:23 To: GRAHAM ASHER Cc: freetype-devel Subject: Re: [ft-devel] cubic clean up Shaded areas Before and After in the attached figures show where control points have should be to permit flattening. Is this a risky change? If anything, it is slightly more conservative, yet the conditional is quite a bit simpler. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
I am really annoyed by run-arounds and overzealous protection of code by authors. I was proposing a minor benign improvement. I am touching the water so to speak. What's the big deal? Way to attract developers, freetypers! You go! ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
I think I can get though to this guy... 2010/11/12 David Bevan david.be...@pb.com: I've just had a brief chance to look at your proposal, and I now understand why it makes no difference to the output. The chances of your relaxed condition causing a split when the current (theoretically correct) condition doesn't is very small: a control point would have to be in the small white areas in the bottom corners of the rectangle in your diagram. Note that this check is only made after subdivisions for the distance from the chord. Since this is the most expensive test, it is done last, and normally only once. Think about it a little more. Imagine a long chord of a dozen pixels. Those white areas are vanishing. Now think about a short chord of a pixel and a half. Those areas are large. However, do you really want to flatten a curve which pitches orthogonally? Think about it. Since there is no performance improvement, I don't believe that your proposal should be included in the code. It would make the code more opaque: It is obvious why the current code [if P1 or P2 is outside P0-P3, split the curve] does what it does (especially if reference is made to Hain's paper); it would not be at all clear why your condition for splitting [if P1 or P2 is far from the center of P0-P3, split the curve] was there. Let's face it. It's only you and me who understand these conditions. You were able to understand my code. Let's drop the opaque argument. I changed the comment for a reason. We can improve it more. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
Aleksei, you really shouldn't be annoyed. My earlier patch was shown to be inferior to David Bevan's, and I was obliged to accept the fact. The only possible criteria are objective ones: does it work? is it faster? is it simpler? I believe David has shown using objective arguments that the patch should not be included. That's not a run-around. It is a courteous consideration of your suggestion, and you should be grateful for it. Also, you don't help your case at all by remarks like I think I can get though to this guy... and It's only you and me who understand these conditions. which are at best patronising and at worst impolite. Best regards, Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: freetype-devel freetype-devel@nongnu.org Sent: Friday, 12 November, 2010 12:16:14 Subject: Re: [ft-devel] cubic clean up I am really annoyed by run-arounds and overzealous protection of code by authors. I was proposing a minor benign improvement. I am touching the water so to speak. What's the big deal? Way to attract developers, freetypers! You go! ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
All, If you at least admitted that my patch would produce a better code... If you at least admitted that my patch is interesting... I would gladly provide more explanation. Instead, I hear should not be applied for some bogus reasons, actually just one reason I do not understand it. Now you are pulling the politeness argument... Please stop. Alexei 2010/11/12 GRAHAM ASHER graham.as...@btinternet.com: Aleksei, you really shouldn't be annoyed. My earlier patch was shown to be inferior to David Bevan's, and I was obliged to accept the fact. The only possible criteria are objective ones: does it work? is it faster? is it simpler? I believe David has shown using objective arguments that the patch should not be included. That's not a run-around. It is a courteous consideration of your suggestion, and you should be grateful for it. Also, you don't help your case at all by remarks like I think I can get though to this guy... and It's only you and me who understand these conditions. which are at best patronising and at worst impolite. Best regards, Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: freetype-devel freetype-devel@nongnu.org Sent: Friday, 12 November, 2010 12:16:14 Subject: Re: [ft-devel] cubic clean up I am really annoyed by run-arounds and overzealous protection of code by authors. I was proposing a minor benign improvement. I am touching the water so to speak. What's the big deal? Way to attract developers, freetypers! You go! ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel -- Alexei A. Podtelezhnikov, PhD ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
On 11/12/10 07:56, Алексей Подтележников wrote: Let's face it. It's only you and me who understand these conditions. Not really. The rest of us just don't care. Because it's just a Bezier flattener after all... No personal attacks on this list. We're grown ups. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
Shaded areas Before and After in the attached figures show where control points have should be to permit flattening. Is this a risky change? If anything, it is slightly more conservative, yet the conditional is quite a bit simpler. attachment: before-and-after.png___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cubic clean up
There is no gain or loss in speed and the quality is the same In that case the patch should not be applied. Any change but the very simplest has some risk. Risk should only be undergone if there is demonstrable benefit. Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: freetype-devel freetype-devel@nongnu.org Sent: Tuesday, 9 November, 2010 0:50:48 Subject: [ft-devel] cubic clean up Hi, This patch should not be controversial. It simplifies the code. 1) It replaces 2 comparisons in FT_MAX and FT_MIN with a single one. 2) It implements a simpler and better check for closeness of control points to the chord There is no gain or loss in speed and the quality is the same (see images). More on 2). Currently the control points are required to be between the parallel lines through the chord ends. The proposed check requires that they are inside a circle. Given an earlier check for the perpendicular distance to the chord, these are actually almost equivalent. So the whole patch is just a clean up. Thanks, Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
