Javascript requestAnimationFrame时间戳限制

我试图写一个基本的游戏循环的基础上。requestAnimationFrame的回调是通过一个timestamp参数传递的，据我所知，这是自页面加载以来的毫秒时间。在构建游戏循环时，我假设每次调用requestAnimationFrame时，时间戳值都会上升，基于此，我可以计算帧之间的时间增量。我唯一担心的是，如果应用程序运行很长时间，这个时间戳值将在某个点达到其极限

---

有这样的限制吗？要实现这一点，需要多少真实世界的时间？达到限制后，时间戳值会发生什么情况？

我认为它不会返回页面加载后的毫秒数，它会返回一个“when

requestAnimationFrame（）

开始执行回调函数”

当需要更新动画时要调用的函数 下一次重新油漆。回调函数只传递一个参数，即

DOMHighResTimeStamp

类似于

performance.now（）

，指示

requestAnimationFrame（）

开始执行回调函数

这就引出了一个问题，所以我还要说，在这种情况下，我不会担心溢出，因为这个单位是一个

双精度单位，我很确定这意味着64位的精度。它花了60年的时间来达到32位的精度。我的数学可能不好，但我不会担心溢出。当时间戳开始出现故障时，我们可能会遇到更大的问题。
别担心。
传递给requestAnimationFrame回调的是一个DOMHighResTimestamp，它的原点设置为窗口（）中的页面加载，实际上它表示此后的毫秒数

根据，在它开始失去精度之前，您有大约285616年的时间。
我认为它不会返回页面加载后的毫秒，它返回“当
requestAnimationFrame（）开始执行回调函数时的时间。”
确切地说是“当requestAnimationFrame（）开始执行回调函数时的时间”开始执行回调函数。“？从我的实验来看，它有点接近页面加载。如果我立即调用requestAnimationFrame-第一个时间戳有点接近零毫秒，如果我在5秒内调用它，因为页面加载-时间戳值将接近5000毫秒。下面的部分中显示了有关回调执行开始时间的信息。我看到2038年的问题是由带符号的32位整数引起的，但这里我处理的是浮点值，即使它是64位。我猜它的存储方式不同，我想知道64位浮点的时间戳的最大值是否比32位整数的时间戳的最大值低。但无论如何，它也必须相当大。如果我正确阅读规格，那么您突出显示的年份与日期对象有关。@MichaelRadiov您可能错过了这句话“DOMTimeStamp的定义与此类似“。由于rAF返回的时间戳的来源是页面加载时间，这是页面加载后的285K年。最长的DOMHigjResTimestamp是performance.timeOrigin，它的原点设置为与Date相同的历元，但这在这里并不重要。事实上，经过一些研究，它看起来是正确的数字。根据和其他来源，可以安全存储在double中的最大int为2^53。如果我们用它来存储毫秒，并将最大值2^53转换为年，我们就得到了您提供的年数。我想如果超过这个最大值会发生什么情况，可以通过添加数字来观察-结果不符合预期。是的，基本上会降低精度，如果到那时仍有一些能源工厂在运行，则可以为运行此脚本的计算机通电。