fix a bug about getting deltaTime as negative #5641
Conversation
| @@ -221,6 +221,11 @@ cc.Director.prototype = { | |||
| if (CC_DEBUG && (this._deltaTime > 1)) | |||
| this._deltaTime = 1 / 60.0; | |||
|
|
|||
| // avoid delta time from being negative | |||
| if (this._deltaTime < 0) { | |||
There was a problem hiding this comment.
我觉得这样判断不是很好，每帧都要做判断。https://developer.mozilla.org/zh-CN/docs/Web/API/window/requestAnimationFrame 。感觉像是requestAnimationFrame的问题，
。要不先确认下是不是这里的问题
There was a problem hiding this comment.
目前看来其实第一帧加载场景的时候执行了一次 resetDeltaTime，然后经历一些过程以后很快就进入 requestAnimationFrame 函数下的 mainloop 了。
now 的获取时机其实是在 resetDeltaTime 之后的，从逻辑上讲这个顺序是没问题，在获取时间绝对正确的情况下，这个值应该永远都大于等于 0。所以问题很可能是出在时间精度上面。
There was a problem hiding this comment.
我觉这样判断应该是可以的，因为问题很大可能是出在精度上面，执行逻辑基本没有问题。
考虑到 performance.now 函数获取的时间和 requestAnimationFrame 函数获取的时间只在每帧 mainloop 中调用 calculateDeltaTime 的时候才在同一个过程中产生联系，若在此之前尝试去更改时间可能会影响到后面每帧的循环逻辑。如果要只对第一帧进行时间判断处理仍会在每帧中进行判断，对第一帧采用完全不同的 requestAnimationFrame 的回调行为也可能产生重复的代码，同时会把帧的循环逻辑复杂化。
There was a problem hiding this comment.
确实是requestAnimationFrame的问题，这个方法传入的now是不准确的，
，导致在第一帧的时候，传入的now可能比performance.now小。
建议把判断修改修改一下，改为
if (this._deltaTime < 0) {
this.calculateDeltaTime();
return;
}
这样就会在 deltaTime小于0的时候，用performance.now 重新计算一次
另外这里补充一下注释，说明一下为什么会有delteTime小于0的情况
There was a problem hiding this comment.
There was a problem hiding this comment.
https://developer.mozilla.org/zh-CN/docs/Web/API/window/requestAnimationFrame
把文档的链接引用上吧
嗯嗯新的 commit 引用上了
Re: cocos-creator/2d-tasks#1555
当获取的 _lastUpdate 值为负数的时候将其更改为 0。
该 bug 会导致 ScrollView 回弹计算有误