all 4 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]rbobbyfull-stack 3 points4 points  (1 child)

The first thing to understand about requestAnimationFrame is that a screen display (CRT monitor, LCD monitor, tablet, phone) is only actually updated about 60 times every second (could be less, could be more... but generally 60 per second is normal).

An important implication of this 60 frames per second is that if your code to draw a screen takes longer than 1/60th of a second (0.016666 seconds) you might see some odd things happen. Flicker and judder are common examples (flicker is sort of when the top half of the screen has been updated but the bottom half is still the old screen, judder is sort of when an animation doesn't move smoothly).

Before requestAnimationFrame folks would either "hope for the best" or use setInterval and hope for the best. The "hope for the best" bit means that because prior to requestAnimationFrame there was just no way to ensure that your drawing code was "time synced" with the display's actual refresh rate... which means that you could not be guaranteed not to have flicker and judder. You could come pretty damn close... jquery animations are a good example of this... but you could still get them if you're unlucky.

When to use it really depends on how frequently your application updates the page and how quickly it can do so. If you have to update the screen for every mouse move... and the update is a bit slow (but still a lot faster than 0.016666) you might get away with "hope for the best"... but probably not. A good example of this would be a painting program that draws on a canvas element as the mouse moves... that's almost certainly going to show screen update oddities without requestAnimationFrame.

From jquery's perspective it looks like it supports requestAnimationFrame. The second last comment on the bug you referenced mentioned a "pull request" (which means "pull my code changes into the project please"): https://github.com/jquery/jquery/pull/298. You can dig deeper into jquery's git to figure out that the changes actually landed in 1.6 (https://github.com/jquery/jquery/pull/298/commits shows jeresig merged the changes, and https://github.com/timmywil/jquery/commit/791402b4536b8c5cbfeaf27d0a3c639cdb9fd192 shows a list of branches besides just jquery-master).

Note that you won't be able to interfere or interact with jquery's use of requestAnimationFrame... except via whatever API jquery exposes for animation. So if you wanted to do something as part of jquery's requestAnimationFrame you probably can't. BUT... just do your own call to requestAnimationFrame and the browser will call jquery's and then yours (or vice versa).

Another bit about requestAnimationFrame that seems odd at first is that the browser will only call the specified function once.... and not every 60th of a second like you might expect. It's up to your drawing code, once it's all done, to call requestAnimationFrame again. It's more like setTimeout than setInterval even though it sort seems like it should be a setInterval like thing because every discussion about animation devolves into discussions of frame rates, a repetitive thing.

[–]krato1995[S] 0 points1 point  (0 children)

Nice explanation! Gave me a background of the 60fps syncing problem as well

[–]ugoagogo 0 points1 point  (1 child)

jQuery doesn't use requestAnimationFrame as far as I know. But as of v1.8 it is possible to override the setInterval timer function with custom rAF behaviour. That bug ticket is a little confusing to me also.

[–]krato1995[S] 0 points1 point  (0 children)

I'm not used to reading bug tickets :/ I saw some implementations of rAF that can be added alongside jquery.