[baddox]

Presumably just listening to the slider state and updating some global variables is fast enough to not need throttling, but I would definitely update the SVG DOM inside a draw loop running in requestAnimationFrame since there's no point in doing it any faster than that anyway.

I'm not an expert on high-frame-rate web drawing, but I've played with it a fair amount, and AFAIK there's no need to do any fancy debouncing logic beyond requestAnimationFrame.

[sagebird]

A need may arise if a calculation took longer than a frame. (I’ve encountered this making a little programming language that generates graphics that updates in real time as you type. I’d imagine similar issues with web based latex-> pdf generators that update the pdf as you type )

[baddox]

If a calculation takes longer than a frame, then you’re going to stutter no matter what you do, right? I feel like the browser will do its best to let you interact with the slider between frames, but really I can’t think of a good way to have a smooth interactive UI with calculations that take more than a frame.