Further reading and prior art

[mfbx9da4]

Hi, brilliantly done! 👏👏

I'm curious about what techniques this code uses and any inspiration for this project.

Is there any reading material you would recommend?

Thanks

[steveruizok]

Hey, thanks! My first steps were intuitive but I found a lot of help along the way from microbians and javidx9's One Lone Coder videos and repos, especially his video on racing lines. I ended up going pretty deep trying to find open source implementations of variable-width lines, which there are not many; but the InkScape source code was useful, as was the source code for the HTML Canvas path stroking implementations. The THREE.Meshline implementation was also useful.

Mostly this project is the result of many tiny improvements (and they're all on Twitter!)

When looking at other curve stuff, unfortunately many of the usual path-fitting algorithms failed for freehand lines.

• For a freehand line to feel correct, the line needed to be as stable as possible except for the very end
• The algo needed to be fast enough to recompute an entire line on every frame

Many implementations approach a problem like this one by creating bezier curves segments that fit together to form the path. In order to make this more effective and more reasonably performant, the path needs to be simplified using an algorithm such as RDP. While this works, it works best with a completed line, or a line where a user is manually editing each width point.

If a simplify-and-fit-curve algorithm is applied while the user is still drawing, the curves will noticeably jump around because each new data set will produce slightly (or greatly) different results. So apps that use this method (such as Illustrator or Figma) will wait until the line is complete before turning it into a smooth curve.

Additionally, finding and creating splines on each frame can be very expensive. To work at speed, it would need a more complex data structure (such as a class or closure) to store the "solved" segments, so that the only the latest segment would need to be solved on each frame. That's also fine (and I might use a pattern like this for a "pro" version of perfect-freehand) but it isn't what I wanted here: I just wanted a function that I could throw points at whenever I needed.

What I ended up with is much more simple than creating splines. It's both stable enough and fast enough that you can re-compute a line with many points (in fact many lines) on each frame without producing different results or creating noticeable performance issues. It relies on other technology (e.g. SVG paths) to produce the final curves, though in this case the browser's rendering is significantly faster than anything I could do with JavaScript.