Changes the way the render loop is called to setImmediate(loop)

[eugeniopacceli]

Addresses the issue #9

In index.ts:79, instead of

setTimeout(() => loop())

I've

setImmediate(() => loop())

or

setImmediate(loop)

with a substantial performance increase (on 120x28 the demo went from avg. ~65fps to ~250fps, on 237x70 it went from avg. ~30 fps to ~64 fps).

Other tests I did were with a while(1) inside the loop function, converting the loop function to an async function and having it's callback call it again, and having the next iteration of the function set up to run with process.nextTick. All of those are also faster than setTimeout, but they seem to hang the process on the loop and disallow other event handlers and callbacks to run.

• This StackOverflow thread on NodeJS' setTimeout(fn,0) vs setImmediate(fn)

• Node's Timers, setImmediate

[sinclairzx81]

Hi, thanks for this :)

The setImmediate() call has actually gone in with a bunch of other optimizations that took place while adding true-color support this afternoon. The original call to setTimeout() was used due to a weird bug with how the application was measuring framerate, where on windows, the Date.now() would intermittently (and mysteriously) return 0ms elapsed between frames when using setImmediate(). This may have been giving inaccurate timings that seem to line up with your observed performance increase.

A different implementation has gone in this afternoon with a new Stopwatch type. The implementation of it can be seen here.

Thanks for the PR tho, it is super appreciated and all PR's are most welcome. But will close this one off as the issue has been resolved.

Cheers S