On Sun, 17 Oct 2010 23:37:52 -0400, Алексей Подтележников said:
>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.
Did you measure this slowdowm, or are you guessing? Why not try a
profiler and see what diffe
On Mon, Oct 18, 2010 at 10:47 AM, Werner LEMBERG wrote:
> Is it? I can imagine that two completely different algorithms are
> best. Cubic and conic curves *are* different beasts...
.. but I managed to quite successfully use essentially the same algorithm
for both.
Regardless of our disagreemen
> It is undeniable that it is so much better to have the same
> algorithm in both conic and cubic splines long term.
Is it? I can imagine that two completely different algorithms are
best. Cubic and conic curves *are* different beasts...
Werner
___
chord.
I agree that the minimum distance should be the same for both pieces of code.
Graham
- Original Message
From: Алексей Подтележников
To: GRAHAM ASHER
Cc: freetype-devel
Sent: Monday, 18 October, 2010 13:11:53
Subject: Re: [ft-devel] harmonize conic and cubic splines
Graha
ype-devel
> 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 (mor
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: Алексей Подтележников
To: freetype-devel
Sent: Monday, 18 October, 2010 4:37:52
Subject: [ft-devel] harmonize conic and
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 th
