Let me clarify the toggling part.

What we did was adding a boolean toggler, var skip = true

if skip is true, we do nothing, and set skip to false
if skip is false, we set skip to true, and run the Director main loop once

This experiment proves that requestAnimationFrame does not run at 60FPS,
because the result is not the game runs at 30fps, but 60fps in chrome/safari, firefox at 25-28fps, ie9 at 45-55fps.
take chrome for example, if requestAnimationFrame runs at 60FPS, then the Director main loop should run at 30FPS, but it actually runs at 120FPS.

if we change the toggler into something like a number ticker, that goes 1,2,3, where it will skip 1,and 2, but main loop runs at 3.
this will make requestAnimationFrame in chrome runs at 180 times a second, producing 60fps.

#### Conclusion

requestAnimationFrame is not a timer that runs at the same refresh rate as the monitor. in Chrome implementation, it tries to make the frame buffer drawn to the screen in sync with the monitor refresh rate.



Regarding saving battery when not visible, we can cancel the setInterval when the browser is not visible, and resume it again when visible. producing the same benefit as requestAnimationFrame.

@saschagoebel Yes, requestAnimationFrame is much more superior to setInterval when you try to make  game that runs at 60fps.

but if you want to make a game that runs 30FPS, you must employ hacky method to make requestAnimationFrame slower. 

picture this, if you floor the accelerator in a race car, it could go at 200MPH,
if you want to make that race car go at 100MPH, would you floor the accelerator AND press the brake at the same time? or you just press the accelerator halfway? (assume automatic transmission)

calculating frame skipping inside requestAnimationFrame does the same as brake+accelerator, using a super inaccurate method to calculate delta time throws the main advance of requestAnimationFrame over setInterval out of the window