什么是人类可检测到的最小滞后？

Question

可能重复:
最短可感知的应用程序响应延迟是多少？

我一直在分析一些JavaScript UI代码,因为它感觉有点滞后.到目前为止,我发现了一些瓶颈并对其进行了优化,但我想为此定义一个可衡量的要求.

为了让人不注意滞后,应该多快发生一次反应？例如,按下键盘键和屏幕上出现字母之间的最小可检测延迟是多少？在什么时候进一步优化不会对人类产生任何影响？

很多显示器的刷新率大约在60-120Hz范围内.这是否意味着幻数约为8-16毫秒？

Answer 1

考虑到"按键"事件和屏幕上出现的字母为两个独立的帧,意味着如果用户在看屏幕时按下一个键,他将希望在之后完全看到它.这"完全在后"意味着它应该具有60Hz或更高的响应时间.

出于这个原因,确实应该瞄准8-16毫秒的值,因为它将导致在电影中看到的相同效果.换句话说,用户将不会对这些值有延迟的感知.

但是,您必须记住键盘具有自己的轮询时间,并且不一定与脚本本身相关的其他延迟可能会干扰其时间.出于这些原因,针对高于60 Hz的值将为您提供更大的安全余量,以抵消可能会增加轻微延迟的其他可能影响.

另外值得注意的是,在某些应用中,延迟100毫秒可能看起来不明显,但事实上它很明显,因为它对应于10赫兹,如果你要以刷新率播放电影,你很可能会意识到每个电影帧之间的差距.出于这个原因,这个值不应该在通用的足够上下文中考虑.

人眼的灵敏度因图像的不同条件和部分而异,因此您应该小心并根据需要考虑更高的刷新率,以适应这种情况.

此链接提供了有关人眼如何感知屏幕特征及其变化​​的更多信息,并可根据脚本的视觉影响,让您了解在特定上下文中应针对哪些刷新率.

Answer 2

作为一般规则,我发现任何比100毫秒快的东西往往被视为"即时".比这更长,延迟肯定会变得明显.当然,这将因人而异,并且还取决于发生延迟的上下文.

您可能会发现此示例很有用:http: //jsfiddle.net/QGmBy/