Using requestAnimationFrame loses time about vue-countdown

[fengyuanchen]

Good discovery. I will improve this soon.

[u01jmg3]

Thanks for making this change so quickly.

However, when comparing to various physical stopwatches over 7 minutes I am finding that the countdown *still* lags behind real time.

Have you tried this type of testing?

[fengyuanchen]

As a browser-side count down component, I think it is hard to be accurate as a physical stopwatch. I guess it may have a deviation of ±0.5s per minute (±8ms per step) when using the window.requestAnimationFrame function.

[u01jmg3]

Do you think it would be a good idea to have a way of not using window.requestAnimationFrame (and instead defaulting to setTimeout())?

[fengyuanchen]

@u01jmg3 See #33.

[klesun]

Hi. We observe that the library still produces a time error that becomes clearly noticeable after an hour of work, the error seems to depend on tab activity.

In my humble opinion the core of the timing issue is actually here:

progress() {
  this.totalMilliseconds -= this.interval;

The library decrements the totalMilliseconds by a fixed interval value not accounting for the real time that tick took which can be off from the requested time by few milliseconds depending on stuff like CPU load - those milliseconds slowly accumulate over time.

I think what would be conceptually correct here is:

progress() {
    this.totalMilliseconds = this.endTime - Date.now();

That way we would eliminate the time error by making totalMilliseconds to get decremented by the effective time that tick took rather than the time that we requested from the unreliable OS.