計時器解析度 Timer resolution (Windows 15.6ms)

原因 ID co-timer · 主要負責 遊戲開發團隊（用戶端開發）

Windows 的預設計時器以 15.6ms 為單位，所以「只休息 1ms」實際上會等到下一個計時器週期，最長拉長到 15.6ms。

為什麼 用 Sleep（短暫等待）的方式實作畫格限制與封包傳送 → 於是 OS 只以 15.6ms 為單位喚醒 → 畫面上 畫格間隔與輸入傳送間隔忽長忽短

症狀: 卡頓
因素: 抖動
誰會遇到: 只有我
何時: 一直都有
負責單位: 主要負責 遊戲開發團隊（用戶端開發）
遊戲開發團隊要做的事: 使用高解析度計時器、改以事件或 V-Sync 為基礎控制節奏，取代 Sleep 等待。
數值參考: 以 15.6ms 為單位無法對準 16.7ms 的間隔，畫格間隔會在 15.6ms 與 31.2ms 之間來回跳動。
圖表上: 一開始就一直偏高 · 畫格間隔分布
查看位置: 查看 PresentMon 的 MsBetweenPresents（畫格間隔）分布，以及 powercfg /energy 報告中的「Platform Timer Resolution」項目（變更過計時器解析度的處理程序）
符合的跡象: 畫格間隔集中在 15.6ms、31.2ms 這類 15.6ms 的倍數，且遊戲沒有要求更高的計時器解析度
不符合的跡象: 間隔平均分散時，比起計時器，更可能是「背景處理程序占用 CPU」或畫格負載
確認方式: 在玩家端環境確認
深入了解: 以前的 Windows 只要有一個程式把計時器改成 1ms，就會套用到所有程式，所以才有「開著瀏覽器遊戲會變順」的說法。從 Windows 10 2004 版起只套用到提出要求的程式，Windows 11 則可能不套用最小化或完全被遮住、也沒有發出聲音的視窗所提出的要求。

出處

_WDF_TIMER_CONFIG (wdftimer.h) Microsoft
一般計時器的精確度是系統時鐘 tick 間隔，預設 15.6ms；高解析度計時器為 1ms
timeBeginPeriod function (timeapi.h) Microsoft
Windows 10 2004 以前為全域設定，之後只套用到提出要求的處理程序；Windows 11 不保證被遮住或最小化視窗的處理程序能取得高解析度
CreateWaitableTimerExW function (synchapi.h) Microsoft
高解析度可等候計時器的旗標 CREATE_WAITABLE_TIMER_HIGH_RESOLUTION
PresentMon Capture Application (README-CaptureApplication.md) Intel
MsBetweenPresents：這次 Present() 呼叫與上次呼叫之間的時間（ms）
Results for the Idle Energy Efficiency Assessment Microsoft
預設系統計時器解析度 15.6ms；可在能源報告的「Platform Timer Resolution」項目找出變更計時器解析度的處理程序
Powercfg command-line options Microsoft
powercfg /energy：分析系統並產生能源報告（HTML）