Use requestAnimationFrame instead of setInterval for animation loop about dragdealer

[ovidiuch]

Nice. Tried this once in one of the failed 2.0s and worked great. The only difficulty is that the current (uninspired) interval is 25 (40fps), and once we update to 16 or whatever the standard is (I remember jQuery had 13) we need to tweak the formulas a bit, otherwise everything will be faster. This is because Dragdealer doesn't use a frame skipping mechanism, different issue...

[w0rm]

Other option I can think of would be running css3 transition if possible and fallback to setInterval.

[w0rm]

What we can do now is debounce mouse/touch events with requestAnimationFrame. This way dragdealer would behave smoother during user interaction.

[ovidiuch]

What we can do now is debounce mouse/touch events with requestAnimationFrame. This way dragdealer would behave smoother during user interaction.

Interesting, is this a common practice to delay user input with requestAnimationFrame? The DOM is updated asynchronously using setInterval, so which part of the event listeners do you think could use debouncing?

[w0rm]

Oh, sorry. If the DOM is updated in setInterval, then there is no need to debounce events. Only perhaps events that calculate offsets and resize event.

I've tried to implement animation using requestAnimationFrame, so FPS meter in Chrome shows 52 instead of 38, when I drag the slider. Of course this change breaks all tests because they depend on setInterval.

[w0rm]

We need to discuss this. I can think of two options.

1. keep two versions of animation (rAF and setInterval), introduce config option that will be set to false for the tests to pass.
2. use polyfill for rAF setTimeout(callback, 25) and think of how to modify tests. I tried tests with polyfill, and they ran completely slow. Seems like jasmine mock of setTimeout doesn't work seamlessly like setInterval.

Option 1) is the simplest and I can commit it right away. Number 2 requires some research on how to rework the tests.

[ovidiuch]

The ideal implementation would be optional polyfill I think, like we did with css translate. The value would be to be able to leverage both new and old browsers. Maybe Jasmine 2.0 performs better on setTimeout...

[w0rm]

Sorry, I might not get you. Do you mean config option will switch to either use rAF with setTimeout polyfill or use current animation based on setInterval?

[w0rm]

I've created another branch and implemented option 1 here but it doesn't use polyfill, it defaults to current implementation if rAF is not available.

[ovidiuch]

Do you mean config option will switch to either use rAF with setTimeout polyfill or use current animation based on setInterval?

Yes, that's what I meant. rAF with setTimeout polyfill seems to have the most value because it spans over all types of browsers and current animation based on setInterval was for seamless backwards compatibility. But honestly if we can get the polyfill working with Jasmine we could give up the current setInterval logic altogether, after all we released a tag prior to this.

I've created another branch and implemented option 1 here but it doesn't use polyfill, it defaults to current implementation if rAF is not available.

Can you open a pull request to see the diff?

[w0rm]

@skidding I opened two pull requests so you can see both ways. #46 can be used right away, as it forces old animation during tests. #47 breaks tests.

[ovidiuch]

Hi, sorry for getting back to you so late. Well the first version doesn't seem to be very useful. Why would someone choose to support IE10+ requestAnimationFrame but not the fallback, while the lib itself does have support for both, just not at the same time.

So the polyfill (2nd one) is clearly what we're aiming for. We can either make the tests pass or maybe make the polyfill optional. Once again have the requestAnimationFrame option but when set to true the entire polyfill solution from #47. This feels like too much technical debt, right?

I'd prefer just the polyfill like #47 but in a consistent way and with the tests passing. For example I wanted to implement frameskipping for a long time now. This might be a good time to have a consistent animation loop implementation based on an entire duration per animation, for both setTimeout and requestAnimationFrame. Hope this makes sense, let me know otherwise. Thanks.

[w0rm]

Hi @skidding. Sorry being late as well, I've just returned from vacations.

I made requestAnimationFrame with setTimeout polyfill completely optional, defaults to false, because it is not tested at the moment. Please check the recent commit and tell me if its what you want.

[ovidiuch]

Hi @w0rm, it seems your pull requests has conflicts. Can you please fix those and then I'll take a closer look?

[w0rm]

@skidding done