Conversation
Adds Domiii's fix and also framerate support, along with rAF fallback for older browsers.
Fix for issue processing-js#92
src/Processing.js
Outdated
There was a problem hiding this comment.
don't leave old code in as a comment: the commit history takes care of making sure deleted code is easily restored.
|
Thanks for the PR, although this will probably need some runtime tests to verify that both |
src/Processing.js
Outdated
There was a problem hiding this comment.
probably want to remove this empty line
|
I hope every1 is aware that modifying the "Animation" loop is the most impactful & risky stuff there is. |
src/Processing.js
Outdated
There was a problem hiding this comment.
While this makes sense from a timing perspective, having this scheduling happen first means that if there are errors in the code that gets called during onframestart, redraw, and/or onframeend, we keep trying to run it over and over. If we want to keep the timing stable, we'll need to a try/catch around the onframe/redraw/onframe block so that if there's a throw anywhere, we catch it, and at the very least set looping to false before throwing the exception on.
However, this function keeps running even if looping is set to false, because the scheduling happens prior to the loop check. That's probably going to cause unnecessary work for the browser, so it'll also be worth switching L4085 and L4086 so that we first check whether to do an early return because we shouldn't be looping, and then request the operation for the new frame, then process the current one.
|
FYI: The following simple sketch tests frame rates and loop start/stop. It begins at the default frame rate. A tap/click in each of the three zones of the square controls behavior as defined below. |
Adds Domiii's quick-fix, plus framerate control, and rAF fallback for older browsers. Tested.