雷锋网按：本文由雷锋网转载自知乎专栏（1）（2），已获作者授权。
先上结论：粗略估算Google Stadia的Controller to Display Latency大概在200ms左右。对比本地游戏，Google Stadia引入的额外延迟在70ms左右。
2019-3-22更新：更精确的测算Google Stadia的Controller to Display Latency在200ms左右，实验误差在208.3±16.7ms内。
14年在做《天谕》引擎的时候，我们遇到了FPS不错，但是“手感”很差的问题。主观测试后，感觉很有可能是输入到画面的延迟（Controller to Display Latency）太高了。但是，怎么来更加客观的分析这个延迟呢？
记得那是一个周末，在公司绞尽脑汁，总不能去买一个高速摄像机来分析吧？当时确实还taobao搜索了一下，印象中都没数清楚后面的0……回想起来可能要几十万吧 〒▽〒，鸟叔肯定不会批的 ╮(╯﹏╰）╭
正绝望中，突然灵机一动，苹果不是刚发布了slow motion功能吗？立马在周末人烟稀少的办公区里一个一个的找手机看，居然真的被我找到了一台支持slow motion的iphone！
打开slow motion，录制了一个最简单的测试：手动控制鼠标左右往复移动镜头，同时拍摄手和显示器屏幕，希望能录下来鼠标和屏幕移动之间的不同步。最终结果比我想象的好的多，不仅清楚的数出了镜头和鼠标之间的延迟帧数，还人生第一次看到了显示器的刷新，真的是从上往下一行一行（实际看到的是n行一起更新）的刷新的！
数出了镜头和鼠标之间的延迟帧数n，又已知拍摄的slow motion的FPS，1000*n/FPS就是延迟的毫秒数。找到了量化延迟的方法后，通过各种hack把driver的三重缓冲干掉（当时还是DX9时代），又修了几个jitter的bug后，迅速就解决了问题。
当时的视频早已不知所踪了，今天，我来用同样的方法测试一下Google Stadia的延迟到底有多少！
刚好在会场遇到了浙大CAD的图形学大牛王锐教授，厚着脸皮让他给我录了一段1分钟的240 FPS slow motionヾ(◍°∇°◍)ﾉﾞ
回到酒店后，打开PotPlayer，继续开始一帧一帧数数~(ﾉﾟ∀ﾟ)ﾉ ，其中一次移动的数据如下：
手柄从最左开始向右摇杆的第一帧：#150
手柄摇到最右停住的第一帧：#179
画面开始向右移动的第一帧：#219
手柄和鼠标有一个很大的区别，摇杆的行程让我没法精确的确定左右摇的精确中点，那就估计一下中点为#165帧，把min/median/max都算一下吧
min：219 - 179 = 40 frames = 167ms
median：219 - 165 = 54 frames = 225ms
max：219 - 150 = 69 frames = 288ms
所以，可以粗略估算Google Stadia的Controller to Display Latency大概在200ms左右。这个值还是相当高的，射击游戏肯定是不行的o(╥﹏╥)o，很是失望~
感谢战神大牛 @gougou槐宏文建议换一种更加精确的方法来测试，减小误差：
谢谢这个文章，但是我有一个小疑问，还需要其他方面的测试来测量，因为输入到摄像机的转动，很有可能出现gameplay code的damping，也就是说输入检测到了但是一开始故意移动摄像机不这么灵敏，这种就是防止摄像机太灵敏，更值得测试的是play control，因为这是玩家操作的，基本不想出现延迟，比如推左摇杆玩家什么时候动，按x键玩家什么时候攻击，如果这些延迟还是200ms，那基本没办法玩
相机平滑+摇杆deadzone等确实有太多的不确定因素了，需要排除掉。按照上述思路重新测试了一下。
视频：
感谢雷火技术中心总监小军路过帮我录像——每次都拉大牛来录，提升逼格 (=´ω｀=)
视频中slow motion部分所有的按键->动作的帧数记录如下：
#629 -> #679 = 50 frames
#1202 -> #1252 = 50 frames
#1748 -> #1796 = 48 frames
#2286 -> #2332 = 46 frames
#2838 -> #2892 = 54 frames
帧数区间是（50±4）帧，平均延迟是49.6帧。在240fps的slow motion下就是206.7ms，误差区间在208.3±16.7ms之内。
这个结果与之前粗略估算的值误差不大，原有的结论仍有有效：
更精确的测算Google Stadia的Controller to Display Latency在200ms左右，实验误差在208.3±16.7ms内。
为啥第一段起名叫做A Black Box Method？因为，今天有一个很棒的讲座：
他里面对延迟的分析非常非常的细致，回答了很多之前我一知半解的模糊概念。我上面用的这种傻大粗的方法，在他的演讲中，就叫做：Black Box Method。
黑盒
Black Box方法完全不管内部细节，直接测量，可以用来分析延迟。但是会导致估计不够细。估计不够细就无法精确预测Throttle从而降低渲染Workload和VSync上的延迟。
这个Talk里面我个人觉得很有意思的几个点：
土豪工作室自己搞了一套闭环检测输入延迟的硬件：
把VSync解释的非常非常清楚
显示器的扫描和刷新
关闭VSync导致画面撕裂
超时+同步点不对=帧率减半
好的同步点只会稍微降低帧率
预测+自适应屏幕分辨率=不会miss任何一个VSync
把延迟的每一步都讲的非常细致，可操作性很强
延迟的定义
提出了人为插入Throttle反而能大幅降低延迟的概念，反直觉
人为插入Throttle反而能大幅降低延迟
提出了具体的估算Throttle的预测算法和Best Practice
Throttle预估算法
反馈机制
此Talk讲的非常细致，等GDC Vault更新视频后，在这里补充链接。#TODO
这个Talk光看PPT很难理解，基本没有文字——好的PPT就应该这样(〃'▽'〃)，需要结合视频食用为佳。心急的同学可以凑活看我的现场速记草稿，基本记录了每一页PPT，侵删：
kilia/gdc2019 中的 ControllerToDisplayLatency现场速记笔记.pdf
由于当时在GDC会场，没有条件测试单机/主机情况下的延迟。评论中大家说的都很中肯，本地游戏的延迟也必须测试才算完整。
张鹤翔：不同游戏的内部延迟不可忽视（即文中所说的游戏收到操控信号到输出一帧画面的时间），条件允许的话需要用不同类型、不同厂商的游戏进行测试才能拿到全面的结果。
对于奥德赛这类动作游戏，本身不要求特别低的延迟，用xbox来测试可能延迟也在100ms以上。
bird cai：你要比较本地连接，单机连接时的延时，再来谈其他。用iPhone Slow Motion也是我们用的方法。我自己测量的结果，在LAN上的结果，网络和串流编码解码的延时可以做到10ms以下。
霞先生：美国DF社好像最新的谷歌云游戏测试，说他们用了高速摄像机，结论是谷歌云延迟是166ms，微软x1x延迟是145ms，感觉差距不大啊
今天，抽空用同事的Steam账号测试了PC版《刺客信条—奥德赛》的延迟情况，感谢最帅气的楠哥提供测试账号。
CPU i9-7900X
GPU GTX 1080
32G DDR4
锁定60fps / VSync ON
《奥德赛》的输入延迟测试
31帧，129.17ms
31帧，129.17ms
33帧，137.50ms
32帧，133.33ms
35帧，145.83ms
35帧，145.83ms
35帧，145.83ms
34帧，141.67ms
33帧，137.50ms
平均33.2帧，在240fps下就是138.4ms。实验测得的数据区间是33±2帧，即137.5±8.3ms。
前文精确的测算Google Stadia的Controller to Display Latency在200ms左右，实验误差在208.3±16.7ms内。
可见，《奥德赛》本身的Controller to Display Latency就是很高的。简单两者对比下Google Stadia引入的额外延迟在70ms左右。
由于感觉《奥德赛》的延迟较高，又拿了最近在玩的FPS游戏，同为UBI出品的《Far Cry 5》进行了对比测试。
17帧，70.83ms
16帧，66.67ms
16帧，66.67ms
15帧，62.50ms
17帧，70.83ms
果然FPS游戏，延迟的优化就要好得多。实验测得平均16.2帧，在240fps下就是67.5ms。实验测得的数据区间是16±1帧，即66.7±4.2ms。
正在生成分享图...
nebula