Hyperapp: Using requestAnimationFrame to improve performance on rendering

Created on 4 Jan 2018  路  4Comments  路  Source: jorgebucaran/hyperapp

Consider the idea of using requestAnimationFrame for rendering DOM. 

function repaint() {
  if (!patchLock) {
    patchLock = !patchLock
    //setTimeout(render)
    requestAnimationFrame(render)
  }
}

Not sure if this is a decision just for simplicity. If so, ignore this ticket ;-)... By the way, good job.

Fran

Inquiry
Source
picture jscriptcoder

Most helpful comment

Hi all,

Wow, that was a super quick answer. Super alive project... Sorry I didn't bother to do some research before dropping the question. I simply landed on the project from an article I read in Medium Digest and first thing I did was to dig into the source code, and found this line.

Once again, great job, and keep it up :-)

Fran

picture jscriptcoder on 4 Jan 2018
👍2

All 4 comments

Hi !

Thank you for your issue, I hope you enjoy to use Hyperapp.

Unfortunately this is a debate we had late in the past, here is the issue when we decided to add raf in core #286.
And sometimes after the issue we took the decision to remove it #422.

Plus, now we removed the use of raf and the mandatory on the Vdom. Hyperapp is now fully usable in a Nodejs context 馃帀

Swizz picture Swizz on 4 Jan 2018
👍2

@jscriptcoder We naively used to do this, but it actually causes issues with background/inactive tabs, so no, we can't switch to rAF. But nothing prevents you from using rAF in your app to "optimize rendering performance" in whatever it is you are doing. 馃槃

From MDN: requestAnimationFrame() calls are paused in most browsers when running in background tabs or hidden