Ember-run-raf

Ember-run-raf uses raf for the Ember Run Loop as well as a suite of tools to complement.

This addon overwrites setTimeout to utilize raf whenever the given wait is null or 0, this has the effect of making backburner utilize raf to flush queues, which is advantageous when your app performs a lot of animation, scrolling, or complex DOM insertions.

This project grew out of smoke-and-mirrors, where these tools were used to reduce scroll jank and ensure that DOM and scroll position manipulation would occur during the same animation frame.

What are the consequences?

requestAnimationFrame is basically a much better setTimeout with a few useful additional behaviors. It's ties to the platform's refresh rate and will execute the given work during the next refresh. Additionally, any work scheduled into it becomes non-DOM affecting until all scheduled work completes.

What that means is one function can manipulate style of content on something, the next function can accurately read that new style or content, but the browser doesn't actually render it until the end.

Some side effect include:

• the browser auto slows or pauses frames when the tab or window is hidden to preserve memory
• it has the effect of coalescing run loops that would trigger close together if you make Ember.run use it
• it reduces scroll and animation jank by ensuring that you aren't flooding your code with callbacks faster than the browser can handle them
• it lets you add content to the DOM, shift the scroll position, and alter that content all without producing a visible change on screen

For callbacks while scrolling, using run.scheduleOnce + requestAnimationFrame has turned out to be a hugely better throttle mechanism than run.throttle. Not only does it perfectly limit the amount of work to be done to the available time to do it, but it additionally ensures that the work is correctly scheduled into the queue at the right time (you would have needed to schedule from within the throttle callback before).

Instead of guessing how often you should execute and spending a ton of time in backburner to do so, your method executes exactly when it next should, in the order it should.

This addon is mostly to start a conversation and to provide the ability to test out the idea and use it in ember applications today. Ideally, a tighter more direct integration with backburner will be possible soon, without overriding setTimeout globally.