On 6/26/07, MenTaLguY <mental@...3...> wrote:

On Mon, 25 Jun 2007 10:48:54 -0400, "bulia byak" <buliabyak@...400...> wrote:

...

On 6/25/07, Bill Baxter <wbaxter@...400...> wrote:

...

Is there any reason why sp-ellipse.cpp uses .552 as the

ellipse-to-bezier

...

constant rather than something with a few more digits:

0.55228474983079356

I guess no reason at all, except that it was that way in Sodipodi and nobody came around to fixing it :) Patches are welcome (I think there are several places in the code using 0.552).

...and, of course, it would be preferable for the patch to define a single constant/macro someplace and use that everywhere, rather than writing out 0.55228474983079356 in a bajillion different places.

I do see that it appears also in dropper-context and dyna-draw-context. That seems to be it. But in those two cases I don't think the accuracy matters. They're both just trying to get something round-ish. They don't really need perfect circle/ellipses for what they're doing. But in the sp-ellipse case it's being used to implement rendering of the SVG arc-to path command, so (short of actually switching to use real elliptical arcs) it should use the best approximation it can get.

But y'know. I just did a side by side comparison, and I can see a lick of difference between an ellipse drawn in inkscape, and the same ellipse rendered by Mozilla or another random drawing program I have lying about. So I guess .552 really is good enuf.

--bb

Bill Baxter wrote:

...

But y'know. I just did a side by side comparison, and I can see a lick of difference between an ellipse drawn in inkscape, and the same ellipse rendered by Mozilla or another random drawing program I have lying about. So I guess .552 really is good enuf.

CAN'T see a lick of difference. I meant CAN'T. And that's with overlaying one directly on top of the other with 50% transparency so I can see one behind the other, not literally looking side-by-side.

Still couldn't hurt to have a constant for clarity.

You ever get 2geom building?

Aaron Spike

On 6/26/07, bulia byak <buliabyak@...400...> wrote:

Can you check if the increased precision fixes any of these bugs, at least partially?

http://sourceforge.net/tracker/index.php?func=detail&aid=1723167&gro...

This one says rotating a circle by 36 degrees results in something of different width than the the original. That's still going to happen even with an improved approximation (unless you special case your approximation for 36 degrees :-)

With the current approximation, a 45 degree rotation turns a width 500 circle into a width of about 499.92. Maximum diameter is at about 18 degrees and that's about 500.11.

With the full constant, the 45 degree width would be exact, everywhere else would be higher. That's what the full constant does, it makes the bez touch the ideal circle at 45 degree angles. Really, that doesn't necessarily mean either minimum peak error or minimal error in the integral sense. In fact with the "correct" constant, it overshoots the radius *everywhere* except multiples of 45 degrees, and has a max radius of 500.136. So in that sense the current approximation is more optimal since the max error is smaller, and since it's sometime bigger and sometimes smaller, it probably has a smaller integrated error.

http://sourceforge.net/tracker/index.php?func=detail&aid=1449053&gro...

I don't think it will help much there either. It'll still be an approximation, so dicing up circles, rotating them, and trying to line them up will still reveal inaccuracies to the tune of 2 parts per 10000.

So 0.552 actually seems to be a pretty good choice after looking at it closer. There's probably some number in that vicinity that really does minimize either max error or integrated error, or RMS error. But it's not going to be a whole lot better -- and they're probably all different numbers -- and I don't happen to know any of those numbers. :-)

--bb