遊戲顯示九十多 FPS，卻在轉身或進入新區域時突然停一下。平均 FPS 並沒有失效，只是它回答得比較粗：這段時間一共產生多少影格。每個影格是否以接近相同的節奏出現，需要另外看時間分布。
分析這種體驗，先看影格時間，再判斷值得繼續測什麼。只憑一個瓶頸百分比或一次 GPU 使用率下降，還不能決定換哪個零件。
長影格可能藏在不錯的平均值裡
理想的均勻輸出下，影格間隔毫秒數約等於 1,000 ÷ FPS。因此 60 FPS 約為 16.67 ms，120 FPS 約為 8.33 ms。這是時間換算，不是某台電腦的跑分。
假設連續 100 個影格中，99 個各用 10 ms，另一個用 100 ms。總時間為 99 × 10 + 100 = 1,090 ms。以總影格數除以總時長，約為 91.74 FPS。平均數字不低，卻仍有一次明顯較長的等待。
圖：人工建構的影格時間演算與複核流程，不是遊戲跑分截圖。
逐影格瞬時 FPS 的算術平均，也不同於總影格數除以總時長。取樣區間、是否包含載入畫面、工具的統計定義，都會改變最終數字。
另一個比「最低 FPS」直觀的量，是慢影格占了多少時間。假設 60 秒有 6 個各 100 ms 的長影格，光這 6 個就用掉 0.6 秒，即全段 1%。這仍是人工演算，但能保留百分位數可能略過的少數停頓。
圖：100 個人工影格。橫軸是影格序號，不是等距時間；第 50 個用 100 ms，其餘 99 個各 10 ms。
先確認記錄哪種影格
NVIDIA 的 FrameView 官方說明列出影格率、影格時間、功耗及日誌功能。[1] 它能保存事件附近的資料，但工具本身無法證明「這是 CPU 瓶頸」。
比較報告前，確認統計的是算繪影格還是顯示影格、影格生成是否啟用，以及垂直同步與上限是否一致。生成影格與基礎算繪影格混比，數字變大不代表輸入反應同比改善。顯示路徑問題也可能在算繪日誌之外，所以平穩日誌不能排除所有視覺卡頓。
「1% low」可輔助觀察低影格表現，但不同軟體可能用不同算法。引用時應保留工具、版本、定義與錄製時長；不要當成最慢一個影格，也不要把不同工具的數字拼成排名。
CapFrameX 刻意區分依影格排序的百分位與持續時間。[3]「99% 影格達到門檻」不能直接改成「99% 遊玩時間流暢」，因為少數慢影格可能占很長時間。它也討論百分位與最慢部分影格的彙總方式；若只有 1% low 標籤而無算法，應保留這個缺口。
哪些日誌欄位值得一起看
開啟 CSV 先核對欄名。PresentMon 主控台文件定義如下；實際輸出取決於版本與擷取參數。[2]
| 欄位 | 文件含義 | 可協助回答的問題 |
|---|---|---|
MsBetweenPresents |
相鄰 Present 呼叫的間隔 | 應用程式提交節奏是否突然拉長 |
MsCPUBusy |
本影格提交前 CPU 工作時間 | 長影格附近 CPU 工作是否改變 |
MsGPUBusy |
GPU 為目標程序此影格工作的活躍時間 | 圖形工作是否隨場景加重 |
DisplayLatency |
影格開始至顯示的時間 | 等待是否在顯示路徑 |
DisplayedTime |
影格在螢幕顯示多久，未顯示可為 NA | 是否有影格停留較久 |
這些時間描述不同區段，CPU 與 GPU 又可並行，不宜直接相加並要求等於總影格時間。MsGPUBusy 也不是工作管理員的 GPU 使用率百分比。先讀定義，才能判斷數字是否適合比較。
若提交間隔拉長且 GPU 活躍時間明顯增加，圖形工作值得檢查；若 GPU 工作短但等待長，上限、CPU 供給或排程都可能參與。後者只縮小範圍，不能直接判為 CPU 性能不足。文件也列出不同 API 和硬體排程的限制，缺失或受限欄位應保持原狀。[4]
用可重複的短路線保存證據
選一段可重走的路線，固定解析度、畫質、鏡頭移動方式與影格上限。先保存設定，再開始擷取並保留檔案。標註遊戲版本、顯示卡驅動、場景與設定，方便之後比較。
觀察尖峰時，記錄是第一次進區域、突然轉鏡頭、背景程式啟動，還是每次經過同處都出現。一起查看已收集的 CPU、GPU、記憶體與儲存資料，不要把沒擷取的感測器欄位填成零。
先重複三次，分別保存。若差異大，核對場景、溫度、快取與背景工作，再決定是否延長或增加測試。只留最佳一次會刪掉需要解釋的波動。
以下是起步範本。60 秒與 3 次只是示範，不保證適用所有遊戲。
| 記錄項 | 範例 |
|---|---|
| 片段 | 固定存檔出發，同路線走 60 秒 |
| 冷啟動 | 第一次進場景另外保存 |
| 重複 | 同設定 3 次，各存 CSV |
| 排除 | 測試前決定選單、載入畫面是否計入 |
| 本輪變數 | 只降陰影，其餘不變 |
冷啟動與已走過一次的場景可分開比較。首次載入卡頓也要留紀錄；比較持續圖形負載時，不能將一組首次載入與另一組暖機後資料混用。
PresentMon 支援依程序名稱選對象、設定時長與 CSV 輸出檔。[2] GUI 或命令列都應先確認目標，避免把啟動器與遊戲混在同一統計。本次未執行遊戲擷取，配圖都是指標演算。
每次只改一個條件
懷疑圖形負載時，降低一項明確算繪負擔後重跑。懷疑背景干擾時，關閉一個已知程式再測。不要同時換驅動、降畫質、解鎖上限又重開遊戲，否則無法知道改善原因。
畫質降低後平均 FPS 上升，但相同位置仍有尖峰，可能表示平均負擔與該卡頓不是同一問題。首次經過卡、之後減輕，可能涉及資源載入或快取，但現象本身不足以確定原因。GPU 使用率低也可能是上限、等待 CPU 或其他限制，不能直接解讀成顯示卡性能不足。
結論應具體到條件，例如「三次都在進區域時出現尖峰，降低陰影後仍在」，而非「電腦有 30% 瓶頸」。下次可直接檢查位置與陰影差異，不必重新猜起。
參考資料
-
NVIDIA FrameView 官方頁面。支援影格率、影格時間與日誌；不表示已實測、所有顯示卡功耗欄位一致或已安裝軟體。
-
PresentMon Console Application 文件。2026-09-27 讀取 main 快照，定義 CSV、程序與時長選項。版本不同欄位會變，未表示本機擷取。
-
CapFrameX: Explanation of different performance metrics。Taxxor，2020-05-31，解釋百分位與 x% low。引用概念，不把舊版介面當目前截圖。
-
PresentMon 說明與限制。2026-09-27 核對。API 與硬體排程會影響測量，應記錄環境而非直接判定瓶頸。
