Javascript Html画布1600x1200屏幕撕裂

我见过一些关于这个问题的问题，但是他们都已经三岁了，通常最后都会说还没有太多的解决办法，所以我想知道是否有什么改变了

我目前正在做一个游戏，它以每秒60次的间隔绘制在画布上。它在我的iphone和PC上工作得很好，它有一个非常好的图形卡，但我现在正在一个装有intel i3 graphics的Thinkcentre上试用它，我注意到一些巨大的屏幕撕裂： -作为一个静物，它更难被注意到

---

我只是想知道是否有任何方法可以减少这种情况，或者轻松启用垂直同步。如果没有，我可以在游戏的windows 8应用程序端口中做些什么吗？

您使用的是requestAnimationFrame（RAF）吗？RAF将进行v同步，但setTimeout/setInterval不会

此外，由于30fps足以让用户看到平滑的运动，将60fps分成两个交替部分如何：

• 一帧期间的“计算/更新”（无图纸）

• 然后在下一帧中绘制所有图形

并且，了解Chrome的时间线工具。这个很棒的小工具可以让你分析你的代码，发现你的代码在哪里花费的时间最多。然后重构这部分代码以获得高性能

[添加：有关requestAnimationFrame的更多有用详细信息]

画布不会直接绘制到显示屏上。相反，画布“渲染”到临时屏幕外缓冲区。“渲染”是指执行画布命令以在屏幕外缓冲区上绘制的过程。下一次屏幕刷新时，此屏幕外缓冲区将快速绘制到实际显示屏幕

当刷新期间在实际显示屏上绘制屏幕外缓冲区时，屏幕外渲染过程仅部分完成时，会发生撕裂

setInterval不尝试将渲染与屏幕刷新协调。因此，使用setInterval控制动画帧有时会产生撕裂

requestAnimationFrame（RAF）试图通过仅在屏幕刷新之间生成帧（称为垂直同步的过程）来修复撕裂。典型的显示器每秒刷新60次（即每16毫秒一次）

使用requestAnimationFrame（RAF）：

• 如果当前帧在下次刷新之前未完全渲染

• RAF将延迟当前帧的绘制，直到下一次屏幕刷新

• 这种延迟可以减少撕裂

所以对你来说，英国皇家空军可能会帮助你解决撕裂问题，但它也带来了另一个问题

您必须决定如何处理物理处理：

• 将其保存在单独的进程中，如setInterval
• 将其移动到requestAnimationFrame中
• 将其移动到web workers中（工作在与UI线程分离的后台线程上完成）

保持物理在一个单独的时间间隔内

这有点像乘坐两列火车，每列火车有一条腿，非常困难！您必须确保物理的所有方面始终处于有效状态，因为您永远不知道RAF何时会阅读物理来进行渲染。您可能需要为物理变量创建一个“缓冲区”，以便它们始终处于有效状态

将物理学引入皇家空军：

如果可以在刷新之间的16毫秒内计算物理和渲染，则此解决方案非常理想。否则，帧可能会延迟到下一个刷新周期。这会导致30帧的速度，这并不可怕，因为眼睛仍能以30帧的速度感知清晰的运动。最糟糕的情况是，延迟有时发生，有时不发生，然后您的动画可能会出现抖动。因此，这里的关键是在刷新周期之间尽可能均匀地分布计算

将物理学引入网络工作者

Javascript是单线程的。UI和计算都必须在此单线程上运行。但是，您可以使用在单独线程上运行物理的web workers。这将释放UI线程，使其专注于渲染和绘制。但是您必须协调后台物理和前台UI

---

祝你的游戏好运：）

那游戏看起来不错badass@cgatian谢谢：）pilower.com这可能是实现requestAnimationFrame的一个很好的起点。@bvx89:同意……我也喜欢这个经典链接，它进一步解释了为什么RAF通常比setInterval/setTimeout更好：太好了，但是我不太明白你说的计算是什么意思，我有一个完全独立的时间间隔，也运行在60帧上，可以进行所有的游戏计算，比如物理等等，我这样做是为了在不影响游戏的情况下更容易地改变抽签率。你检查了requestAnimationFrame（RAF）了吗？RAF结构可能有助于您进行删除，因为回调是相对于浏览器刷新调用的。我所说的“计算”实际上是指在绘制之前必须进行的任何物理计算。我已经更新了关于RAF.OP的更多细节：WebWorkers+类型化数组（因为它们可以作为引用而不是副本传递）可能是进行物理计算的好方法。