Jank-free rendering & shared tickers (WIP)

I added a setValue function that acts as sugar for updating config and starting. This is somewhat akin to setEndValue in rebound. Name of method is totally up for debate.

Second, I added a raf config option (again, name up for debate) that stops _step() from registering its own requestAnimationFrames. With raf: false all spring advancing must be done manually.

That said, I mangled the living hell out of _step and advanceSpringToTime in order to get this to work.

It needs some cleaning up. Perhaps _step becomes what _advanceSpring is now? Usually in GL land step/tick functions are called by your main draw loop to do whatever time-based advancing they need to do, so there'd be some parity to existing convetions that way.

Finally, check out the squares demo I added (again it's messy). If you watch the performance monitor heap allocation remains constant and there's only a single raf frame :thumbsup:

Thanks for contributing!

I'd like to see more context. Were there issues you were running into that led to these changes? Can we separate them out into individual pieces (e.g. setValue sugar, skipping raf, using loops instead of literals) so we can discuss them independently?

Personally, I'm skeptical of changes that only have theoretical benefits or suit a personal style. If you can say "it drops frames when there are more than 4 springs running on this class of device," I'm more amenable to changes than "this is theoretically faster if you have eleventy million springs instantiated per frame."

I don't mean to be a skeptic or pedant, but I would like to understand the motivation for changes before commenting on or approving them.

Also, since this is a microlibrary, I'm especially conservative about API sugar. I don't see much benefit of setValue(toValue) vs updateConfig({ toValue }), but replacing updateConfig with setters will impact file size.

https://github.com/skevy/wobble/issues/9 https://github.com/skevy/wobble/issues/8

I've been using my fork for a while now and have significantly less jank. My use case is with webgl drawing as many thousands of verts as I can as smoothly as I can. Every major/minor GC results in a noticeable hiccup and drop from 60fps, so this pull is about providing pathways that avoid all memory allocation so gc's don't even happen.

Charts are nice, so here's a couple.

Here's the js heap size using wobble normally (letting it make its own requestAnimationFrames and using updateConfig({toValue: value})

Edit: forgot that the above is also on my PR branch, so this is probably a bit better still than skevy/wobble/develop because of the changes I made in updateConfig to reduce allocations

And here's the exact same demo using {raf: false}, setValue(value), and tick/_advanceSpringToTime:

Half the cpu usage, half the memory usage and no GCs. 👍

Any thoughts?

Any hopes of getting this PR merged? I know its been a long time 😅

Author doesn't really seem interested. Might as well use my fork if performance is important to you.

That is indeed what I was considering in case there was no response! Thanks 🙂