getPointAtLength results are very different compared with native svg getPointAtLength about svg-path-commander HOT 18 CLOSED

The codepen in issue is throwing me an error and I can't examine/fix it right away.

Like how much different is the result? Because I know about an acceptable margin of error, not exactly a major crack in the sky.

from svg-path-commander.

I fixed the codepen :)

from svg-path-commander.

Yea, that looks like an acceptable margin of error to me and I will explain why.

I developed this script from SVGPath, Raphael and other sources, modernized everything for best modular implementation and performance basically the best JavaScript I know. The main purpose of this library is to provide the tools I need for KUTE.js for morph SVG components.

Now these sources use utilities from other sources to provide the computation of mostly what is clearly a best guess approximation. My input in those is basically none. With other words, SVGPathCommander should basically output same getPathLength as Raphael, our advantage is that we have a modern code base that is actually usable in Node.js and anything that can run JavaScript. You get some actual numbers you can use without the native SVG API.

If I remember correctly, in my calculation our output might actually be more accurate than the native implementation which is basically as old as the SVG 1.1 draft. Some say the native getTotalLength sometimes is wrong when certain SVG attributes are used, perhaps this can give you a hint. Basically non-Chrome browsers, as well as early Chrome, used to throw a wide range of values around.

I will tell you this: our getPathLength provides better values for animating strokes, don't ask me how I know, but this is how I know these are all approximations.

At the moment I don't have the time to investigate all possible alternatives for you, but if you find one that is math perfect, you have to let me know.

So yea, take it from here.

from svg-path-commander.

For completeness I made a new codepen and included Raphael, Snap.svg and also svg-path-properties. I think Raphael and Snap.svg use native functions so the results are the same as native svg. If the margin is acceptable for you, that's ok. That is not the problem though. The problem is that there is a wrong result if I try to find the point at 50% of the total length. It gives the same result as the point at length 0 (zero) or 1 (total length).
(in the codepen there is no red dot on the left side - at 'total length * .5)

(link does not seem to work, take url and put it in the browser)
https://codepen.io/krisheyse/pen/dyOoKzj?editors=0111

cheers :)

from svg-path-commander.

the link does not seem to work. just put the url in the browser :)
fixed link see edit

from svg-path-commander.

Alright, lemme throw this around:

• try changing the round option to something "more accurate", before the SVGPathCommander invokation, paste this code SVGPathCommander.options.decimals = 9 (the default value is 3)
• lemme know how the numbers go

from svg-path-commander.

I think the numbers should be almost the same.

However, I'm looking at the original source from Raphael, which is a completely different implementation compared to mine.

My implementation is small and quick, but very close to the native calculation, better than svg properties :)

from svg-path-commander.

I will have a look, thanks for this awesome report.

from svg-path-commander.

So yea, Raphael = Snap.svg, they both use native in the browser, and the function I linked above in other environments or legacy browsers.

from svg-path-commander.

@eltapir After I've set the rounding to 9 decimals in your example I can see the red dot :)

from svg-path-commander.

Ok, I can see the red dot as well. Problem solved, thanks :)

from svg-path-commander.

It also works with 4 decimals :)

from svg-path-commander.

I think I will add 9 decimals to those methods by default.

from svg-path-commander.

@eltapir get ready to learn:

const PCEllipseLength = SVGPathCommander.getPathLength(ELLIPSE_PATH_STRING); // 4 decimals
// returns Red: SVGPathCommander - length ellipse: 916.4210437745604

const snapEllipseLength = Snap.path.getTotalLength(ELLIPSE_PATH_STRING); // the real utility from SNAP, and not Element.getTotalLength()
// returns Green: Snap - length ellipse: 916.4210437748001

const rafEllipseLength = Raphael.getTotalLength(ELLIPSE_PATH_STRING); // the real Raphael utility
// returns Orange: Raphael - length ellipse: 916.4210437748001

I say that's incredibly "accurate", don't you think?

from svg-path-commander.

Indeed, that's very very accurate.

from svg-path-commander.

OK now, you can check the latest version 0.1.2, you can now do

const pathLength = SVGPathCommander.getPathLength(pathString,decimals)

from svg-path-commander.

Here's your test with the latest "master" version.

from svg-path-commander.

And now should be almost perfect:

from svg-path-commander.