使用垂直同步時接受的時間策略是什麼？

Question

從OpenGL的編程的基本理解編輯，所有需要的繪圖操作在序列執行每幀重繪一次。硬件的性能決定了它發生的速度。據我所知，遊戲將盡可能快地繪製，這樣重繪操作基本上被包裝在一個while循環中。圖形操作（圖形引擎）將進行優化，以確保幀速率適用於應用程序。

圖形硬件支持垂直同步然而鎖定幀速率顯示速率。第一個問題是圖形引擎應該如何與硬件同步交互？這甚至是可能的，或者渲染器以最大速度工作，並且硬件選擇性地調用最新幀，丟棄所有未使用的先前幀。

對這個問題的動機是不是，我打算馬上寫了一個圖形引擎，而不是正在調試的問題與在移動場景的圖形出現在屏幕上口吃現有系統。在症狀方面，當VSync關閉時，打開時口吃會很輕微，打開時有明顯的週期性口吃或口吃完全解決。爲了理解圖形系統的一些更多背景信息，我有點緊盯着正在發生的事情或原因。

綜上所述問題將是對一個預期如何與硬件交互重繪事件，如果這甚至有可能。然而，任何額外的信息將受到歡迎。

Answer 1

這是一個猜測，但：

問題不是垂直同步

我不知道你正在使用什麼操作系統，但也有不同的方法來獲取有關信息顯示器以及屏幕刷新速度有多快（爲了達到這個目的，我們假定你的顯示器有點新近，並且以60Hz的頻率，或者每秒60次，或者每16.66666毫秒重繪一次） 。

渲染器通常與應用程序的「邏輯」端配對：輸入，UI計算，仿真運行等等。看起來應用程序的邏輯端運行得很快，但渲染端 - 即它通常概括的Draw Call--就是你的應用程序的速度。

垂直同步可以在加劇這個，如果你的繪圖調用，以每16.66666毫秒發生 - 但它需要更長比16.666666毫秒 - 那麼你感知幀率下降（即框架將「口吃」，因爲他們花費太長時間才能製作出單幀）。垂直同步 - 和有利或它們禁用 - 不是那種瓶頸您的代碼：它只是說，「哎，因爲硬件只會拿1幀從我們的每16.666666毫秒，爲什麼還要讓更多的繪製調用不僅僅是一個每16.66666毫秒？只要我們每次都經過一次畫電話，我們的應用程序就會盡可能流暢，我們不必浪費時間撥打更多的電話！「

問題是，它假定你的代碼將運行足夠快使它在那些16.6666毫秒。如果沒有，屏幕上會出現口吃，滯後，視覺僞影，凍結幀和其他事情。

當您關閉垂直同步，你告訴你的渲染通話將被儘可能多地調用，儘可能快。這可能會給邏輯調用帶來一些額外的擺動空間以獲得渲染幀，這樣當硬件說「我要拍照並將其放在屏幕上！」時所有這些都是在準備好時間之前進入的姿勢，並說cheese!（儘管按照你的說法，它幾乎沒有成功）。

該怎麼做：

開始通過剖析你的代碼。瞭解哪些功能花費最多時間。通過口吃來判斷，代碼中的某些內容花費的時間比預期的要長，並且會給您帶來不理想的表現。確保輪廓第一個發現你燒掉時間，其中的關鍵部分，並找出如何保持正確和使它一樣快。你可能想知道在渲染調用中調用的是什麼，並描述完成一個具體週期所需的時間。然後計算邏輯調用並查看執行這些操作需要多長時間。然後，砍掉。

祝你好運！

Answer 2

第一個問題是圖形引擎應該如何與硬件同步交互？

爲了避免閃爍現代渲染系統使用雙緩衝即有兩種色彩平面緩衝器和精加工繪製一個之後，顯示讀數指針被設置到成品緩衝平面。這緩衝區交換可以發生同步或非同步。啓用V-Sync後，緩衝區交換將被同步，渲染線程將被阻塞，直到發生緩衝區交換。

由於使用雙緩衝強制緩衝區交換，這隱含地引入了同步機制。這就是交互式渲染系統如何鎖定顯示刷新。

症狀上，當VSync關閉時，打開時口吃會很輕微，打開時有明顯的週期性口吃或口吃完全解決。

這聽起來像一個寫的不好動畫循環，它假定恆定幀率鎖定到顯示刷新速率，根據該幀呈現比顯示刷新間隔和緩衝交換更快可以及時發出用於下一個假設回溯發生。

處理垂直同步的唯一可靠方法是實際測量幀渲染之間的時間並將渲染循環提前一段時間。