我见过几个关于这方面的问题，但他们都已经三岁多了，通常最后会说还没有什么办法解决，所以我想知道是否有什么变化。
我目前正在开发一款游戏，它以每秒60次的间隔绘制在画布上。它在我的iphone和PC上运行得很好，它有一个故障严重的显卡，但我现在正在使用英特尔i3显卡的Thinkcenter上试用，我注意到一些巨大的屏幕撕裂：http://s21.postimg.org/h6c42hic7/tear.jpg-作为剧照，这有点难以察觉。
我只是想知道是否有任何方法可以减少这种情况，或者轻松启用垂直同步。如果没有，我可以在游戏的windows8应用程序端口中做些什么吗？
您正在使用requestAnimationFrame（RAF）吗？RAF将进行v-sync，但setTimeout/setInterval不会。
http://msdn.microsoft.com/library/windows/apps/hh920765
此外，由于30fps足以让用户看到流畅的运动，不如将60fps分成两个交替的部分：
-
在一帧（无绘图）期间"计算/更新"
-
然后在下一帧中绘制所有图形。
了解Chrome的Timeline工具。这个很棒的小工具可以让你分析你的代码，发现你的代码在哪里花的时间最多。然后重构代码的这一部分以获得高性能。
[添加：有关requestAnimationFrame的更多有用详细信息]
画布不会直接绘制到显示屏上。相反，画布会"渲染"到一个临时的屏幕外缓冲区。"渲染"是指执行画布命令在屏幕外缓冲区上绘制的过程。当下一次屏幕刷新发生时，这个屏幕外缓冲区将被快速绘制到实际显示屏上。
当刷新期间在实际显示屏上绘制屏幕外缓冲区时，屏幕外渲染过程仅部分完成时，就会发生撕裂。
setInterval不尝试将渲染与屏幕刷新相协调。因此，使用setInterval控制动画帧偶尔会产生撕裂。
requestAnimationFrame（RAF）试图通过仅在屏幕刷新之间生成帧来修复撕裂（这一过程称为垂直同步）。典型的显示器每秒刷新约60次（即每16毫秒刷新一次）。
有请求的动画帧（RAF）：
-
如果当前帧在下一次刷新之前没有完全渲染，
-
RAF将延迟当前帧的绘制，直到下一次屏幕刷新。
-
这种延迟减少了撕裂。
所以对你来说，RAF可能会帮助你解决撕裂问题，但它也会带来另一个问题。
你必须决定如何处理你的物理处理：
- 将它保存在一个单独的过程中，比如setInterval
- 将其移动到requestAnimationFrame中
- 将其移动到web Worker中（工作在独立于UI线程的后台线程上完成）
将物理保持在单独的集合Interval中
这有点像坐两列火车，每列火车一条腿——非常困难！你必须确保物理的各个方面始终处于有效状态，因为你永远不知道英国皇家空军什么时候会阅读物理来进行渲染。您可能需要为物理变量创建一个"缓冲区"，以便它们始终处于有效状态。
将物理学带入RAF:
如果您可以在刷新之间的16毫秒内计算物理和渲染，则此解决方案是理想的。否则，帧可能会延迟到下一个刷新周期。这导致30fps，这并不可怕，因为眼睛仍然可以在30fps下感知清醒的运动。最糟糕的情况是，延迟有时会发生，有时不会发生——然后您的动画可能会出现抖动。因此，这里的关键是在刷新周期之间尽可能均匀地分布计算。
将物理学应用于网络工作者
Javascript是单线程的。UI和计算都必须在此单个线程上运行。但是你可以使用在一个单独的线程上运行物理的网络工作者。这将释放UI线程，以便集中精力进行渲染和绘制。但是您必须协调背景物理和前景UI。
祝你的游戏好运：）