Use RAF's timestamp for smoother animations #3143

joliss · 2016-06-06T19:44:02Z

jQuery 3.0.0-rc1 uses requestAnimationFrame, resulting in significantly smoother animations compared to before. However, its tweening logic uses Date.now() instead of the RAF timestamp argument. As a result, the animation is still slightly choppy.

Before you switch to using timestamp, I should point out that the Velocity.js library opts not to use timestamp (velocity.js:3366):

/* We ignore RAF's high resolution timestamp since it can be significantly offset
   when the browser is
   under high stress; we opt for choppiness over allowing the browser to drop huge
   chunks of frames. */
var timeCurrent = (new Date).getTime();

I don't know if this is actually still an issue in modern browsers. @julianshapiro originally wrote this code in 2014 -- perhaps he can chime in with some details.

I created a test case to demonstrate choppiness resulting from not using timestamp: https://codepen.io/joliss/pen/wWKGeV/ (The test case uses Velocity.js, but I believe it's the same for jQuery.)

My hope is that you can use this test case as a debugging aid, and as a motivating example to convince browser vendors to get any remaining timestamp issues resolved.

Running the CodePen, we see that there is some slight choppiness with the jQuery's getTime implementation:

Using the RAF timestamp argument instead, the animation feels smoother, and the graph is perfectly smooth as well:

I thought that perhaps using the microsecond-resolution performance.now() function would improve smoothness, but it doesn't seem to help much:

The text was updated successfully, but these errors were encountered:

mgol · 2016-06-06T21:45:38Z

A great analysis, thanks a lot! I'm surprised that using performance.now() gives worse results than using the timestamp since it's based on the same timer.

I made a quick patch for jQuery 3.0.0-rc1 that made it use the rAF timestamp:
https://gist.github.com/mgol/59155e734d86095f58d505824f7503c2
and added a button for it in your test case:
http://codepen.io/mgol/pen/VjvjdL

The graph looks similar to the Velocity using timestamp one.

Note that I'm seeing the performance difference in Chrome 51 but I don't see any gain in Safari (9.1 & TP) and Firefox; Safari mostly looks like your "Velocity plus performance.now" test case in all cases (including the getTime one in which it's better than Chrome), Firefox looks terrible in all cases. I'm not sure if doing sth like that just for Chrome is worth it... :/

EDIT: In Edge 13 all cases look the same, worse than in Safari but way better than in Firefox.

mgol · 2016-06-06T22:12:16Z

Re Firefox: the terrible graphs that I'm seeing are there only if I use the integrated graphics card in my MacBook. i.e. Intel Iris Pro 1536 MB. If I switch to the dedicated AMD Radeon R9 M370X 2048 MB, it gets closer to Safari. Perhaps Firefox has problems with hardware acceleration for Intel GPUs.

julianshapiro · 2016-06-06T22:16:53Z

I've always found that dropping a huge chunk of frames upfront is more visually jarring than an FPS hit. In real world (low-stress) animation scenarios, the FPS hit isn't that noticeable — if at all.

joliss · 2016-06-06T22:55:12Z

@mgol Good point. I created an issue on the Firefox bug tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1278408 Let's see what they say, and if necessary we can create issues on Edge and Safari too.

@julianshapiro I agree dropping chunks of frames is really bad. Is this still happening though? (Or to be more precise, is it worse for timestamp compared to Date.now()?) Plotting timestamp values with a no-op requestAnimationFrame, I don't see any initial framedrops: https://codepen.io/joliss/pen/ZObOPm

timmywil · 2016-06-07T15:44:17Z

Very cool. Thanks for this.

digitarald · 2016-06-07T16:31:25Z

I also updated the bug with a reference to an older bug on which I added @bzbarsky to take a deeper look.

markelog · 2016-06-08T02:32:57Z

Nice test!

Judging by the discussion in mozilla thread we still can't use it right? After it will be fixed (fingers crossed), we still should look at older/other browsers that we support?

dmethvin · 2016-06-08T08:33:23Z

On Firefox 46 with Windows 10 it looks as smooth as Chrome. As long as we don't make things much worse on Firefox by changing to the rAF timestamp is there anything to stop us from changing it now? To @markelog's point we would also need to ensure it doesn't degrade too much for browsers like Android or IE9.

mgol · 2016-06-08T09:25:40Z

@dmethvin My quick patch made jQuery.fx.tick accept a timestamp parameter so that'd slightly change the API; to avoid that we'd need a wrapper function which might increase the code size a little.

I just don't see much gain in using the timestamp until it improves the situation only in Chrome. Maybe as a way of preparing for the future? I can prepare a PR to discuss the details further.

mgol · 2016-06-08T09:26:55Z

Ah, you said it's as smooth as Chrome for you in Firefox on Windows 10. Do you mean it looks like the same graph as the second one from the original @joliss post, completely smooth? That'd change the situation. :)

dmethvin · 2016-06-08T09:39:02Z

Yeah, here are my Firefox results, very smooth:

markelog · 2016-06-08T09:58:00Z

In here @mgol points out that timestamp dependant on graphics card (@dmethvin your card might just be in "good" category), is it not case? The same story could be with other browsers?

This https://bugzilla.mozilla.org/show_bug.cgi?id=1278408#c10 is also disturbing

markelog · 2016-06-08T09:58:26Z

Also, if we can do this and it is not the issue, why those tickets are open?

mgol · 2016-06-08T12:31:12Z

In here @mgol points out that timestamp dependant on graphics card (@dmethvin your card might just be in "good" category), is it not case?

Possible. The current data points to the thesis that it's never worse when using the timestamp than when not using it and sometimes it's better.

In some environments that support the requestAnimationFrame timestamp callback parameter using it results in smoother animations. Fixes jquerygh-3143

mgol · 2016-06-08T12:52:10Z

PR: #3151. Please review.

In some environments that support the requestAnimationFrame timestamp callback parameter using it results in smoother animations. Fixes jquerygh-3143

mgol · 2016-06-22T11:19:16Z

CC’ing Mozilla folks: @miketaylr @digitarald @bzbarsky @annevk @kentuckyfriedtakahe @cyberdees

In some environments that support the requestAnimationFrame timestamp callback parameter using it results in smoother animations. Fixes jquerygh-3143

In some environments that support the requestAnimationFrame timestamp callback parameter using it results in smoother animations. Note: the rAF timestamp is using the same API as performance.now() under the hood so they're compatible with each other. However, some browsers support rAF (with a timestamp parameter) but not performance.now() so using them both would introduce an error. This commit stops using rAF in browsers that don't support performance.now(). From all the browsers jQuery supports this only affects iOS <9 (currently less than 5% of all iOS users) which will now not use rAF. Fixes jquerygh-3143 Closes jquerygh-3151

mgol · 2017-03-15T16:15:07Z

Pushing to at least 3.3.0 as Chrome apparently has a bug that makes timestamps arrive to our step function not always in ascending order. See #3151 (comment) for more details.

In some environments that support the requestAnimationFrame timestamp callback parameter using it results in smoother animations. Note: the rAF timestamp is using the same API as performance.now() under the hood so they're compatible with each other. However, some browsers support rAF (with a timestamp parameter) but not performance.now() so using them both would introduce an error. This commit stops using rAF in browsers that don't support performance.now(). From all the browsers jQuery supports this only affects iOS <9 (currently less than 5% of all iOS users) which will now not use rAF. Fixes jquerygh-3143 Closes jquerygh-3151

mgol · 2018-10-03T11:13:59Z

This requires more investigation, with issues around out-of-order scheduling in Chrome that I've experienced as well as recent timer throttling due to Spectre. Postponing to 4.0.0.

In some environments that support the requestAnimationFrame timestamp callback parameter using it results in smoother animations. Note: the rAF timestamp is using the same API as performance.now() under the hood so they're compatible with each other. However, some browsers support rAF (with a timestamp parameter) but not performance.now() so using them both would introduce an error. This commit stops using rAF in browsers that don't support performance.now(). From all the browsers jQuery supports this only affects iOS <9 (currently less than 5% of all iOS users) which will now not use rAF. Fixes jquerygh-3143 Closes jquerygh-3151

joliss mentioned this issue Jun 6, 2016

Test case to show choppiness resulting from not using RAF timestamp julianshapiro/velocity#684

Closed

mgol added a commit to mgol/jquery that referenced this issue Jun 8, 2016

Effects: use requestAnimationTime timestamp if available

51b27b0

In some environments that support the requestAnimationFrame timestamp callback parameter using it results in smoother animations. Fixes jquerygh-3143

mgol linked a pull request Jun 8, 2016 that will close this issue

Effects: use requestAnimationFrame timestamp if available #3151

Draft

6 tasks

mgol added a commit to mgol/jquery that referenced this issue Jun 8, 2016

Effects: Use requestAnimationFrame timestamp if available

c0d0594

In some environments that support the requestAnimationFrame timestamp callback parameter using it results in smoother animations. Fixes jquerygh-3143

salzhrani mentioned this issue Jun 12, 2016

Use RAF timestamp argument if available chenglou/react-motion#340

Merged

timmywil added the Has Pull Request label Jun 30, 2016

timmywil added this to the 3.2.0 milestone Jun 30, 2016

markelog added the Effects label Jul 4, 2016

oori mentioned this issue Aug 13, 2016

Use requestAnimationFrame's build in high precision timestamp facebookarchive/rebound-js#22

Closed

mgol modified the milestones: 3.2.0, 3.3.0 Mar 15, 2017

timmywil assigned mgol Mar 27, 2017

timmywil modified the milestones: 3.4.0, 3.3.0 Jul 24, 2017

timmywil changed the title ~~We should use RAF's timestamp for smoother animations~~ Use RAF's timestamp for smoother animations Sep 17, 2018

mgol modified the milestones: 3.4.0, 4.0.0 Oct 3, 2018

timmywil modified the milestones: 4.0.0, 3.7.0 Aug 26, 2022

timmywil modified the milestones: 3.7.0, 4.1.0 Feb 13, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use RAF's timestamp for smoother animations #3143

Use RAF's timestamp for smoother animations #3143

joliss commented Jun 6, 2016 •

edited

mgol commented Jun 6, 2016 •

edited

mgol commented Jun 6, 2016

julianshapiro commented Jun 6, 2016 •

edited

joliss commented Jun 6, 2016

timmywil commented Jun 7, 2016

digitarald commented Jun 7, 2016

markelog commented Jun 8, 2016

dmethvin commented Jun 8, 2016

mgol commented Jun 8, 2016

mgol commented Jun 8, 2016 •

edited

dmethvin commented Jun 8, 2016

markelog commented Jun 8, 2016

markelog commented Jun 8, 2016

mgol commented Jun 8, 2016

mgol commented Jun 8, 2016

mgol commented Jun 22, 2016

mgol commented Mar 15, 2017

mgol commented Oct 3, 2018

Use RAF's timestamp for smoother animations #3143

Use RAF's timestamp for smoother animations #3143

Comments

joliss commented Jun 6, 2016 • edited

mgol commented Jun 6, 2016 • edited

mgol commented Jun 6, 2016

julianshapiro commented Jun 6, 2016 • edited

joliss commented Jun 6, 2016

timmywil commented Jun 7, 2016

digitarald commented Jun 7, 2016

markelog commented Jun 8, 2016

dmethvin commented Jun 8, 2016

mgol commented Jun 8, 2016

mgol commented Jun 8, 2016 • edited

dmethvin commented Jun 8, 2016

markelog commented Jun 8, 2016

markelog commented Jun 8, 2016

mgol commented Jun 8, 2016

mgol commented Jun 8, 2016

mgol commented Jun 22, 2016

mgol commented Mar 15, 2017

mgol commented Oct 3, 2018

joliss commented Jun 6, 2016 •

edited

mgol commented Jun 6, 2016 •

edited

julianshapiro commented Jun 6, 2016 •

edited

mgol commented Jun 8, 2016 •

edited