[londons_explore]

I suspect it took mouse events, and initially drew straight lines between them. That's necessary on 1990's hardware because drawing straight lines is fast, and you need to do it fast.

Then, when you are done drawing, it redraws the line, using the same points as before, but this time as input to a spline curve algorithm.

Drawing splines isn't much harder computationally, but notably if you add one more point to the end of a spline curve, then part of the line that you have already drawn changes. That in itself is very computationally heavy, since everything behind that line now needs to be redrawn - certainly not something you can be sure can be done at 60 fps!

[steveruizok]

Drawing lines is faster than you think! The perfect-freehand algorithm that I wrote / that canva is using here does not use splines but it does recompute the entire line on every frame. It’s fine at 60fps (and also fine at 120fps) up to a few thousand points on somewhat modern hardware before the paths get too slow to render. The algo itself is just blazing fast, in part because it does not rely on splines (which are much more complex).

For an svg-style approach to ink (as opposed to a raster / dab-style brush) there’s no other option than recomputing the whole line each time. As a bonus, you can adjust the properties after the fact very easily. (You can try that at perfectfreehand.com.)

[londons_explore]

But on 90's hardware, you still have no compositing or back buffers, so if you want to 'move' previous bits of line, you must redraw the background, which is the expensive bit.

[jaza]

I don't deal with splines much, but when I do, I'm reticulating splines.