- 500Hz ekranda tıklamadan ekran parlaklığındaki değişime kadar yapılan ölçümlerde, X11·VRR·dxvk-low-latency’nin tümü uygulansa bile varsayılan Wayland’e kıyasla uçtan uca gecikme medyanı yalnızca 0,72ms daha düşük çıktı
- Yerel Wayland, X11’den 0,14~0,22ms daha yavaşken, XWayland yerel Wayland’e kıyasla en fazla 3,13ms ekleyerek çok daha büyük bir fark yarattı
- Değişken yenileme hızı (VRR) tüm karşılaştırmalarda gecikmeyi 0,26~0,45ms azalttı; p5~p95 dağılım genişliğini de 2,6~3,0ms’den 2,1~2,2ms’ye daralttı
- dxvk-low-latency, kare sınırlaması varken 0,10~0,29ms, sınırlama kaldırıldığında 0,84ms azalttı; ancak ikinci durumda GPU kullanımını %100 yerine %95~97’de tutarken FPS 715’ten 670’e düştü
- Sonuçlar, kararlı FPS ve CPU darboğazı gibi ideal koşullarda ve belirli bir donanım-yazılım birleşiminde elde edildi; gerçek oyunda VRR’nin jitter azaltması ve frame pacer’ın render kuyruğunu bastırması, medyandan daha büyük farklar yaratabilir
Optimizasyon tavsiyelerini doğrudan doğrulama nedeni
- Linux oyunlarında Wayland yerine X11 kullanma, compositing’i devre dışı bırakma, gecikme optimizasyonlu DXVK fork’u, oyun odaklı kernel scheduler, gamescope·gamemode·ortam değişkenleri uygulama gibi çok sayıda optimizasyon tavsiyesi bulunuyor
- Rekabetçi FPS oyunlarında düşük gecikme, tutarlı frame time ve yüksek FPS önemlidir; ancak ayar değişikliğinin gerçek bir iyileşme mi yoksa plasebo ya da ters etki mi olduğunu doğrulamak zordur
- Ölçüm cihazının donanımı, muhafazası, firmware’i, analiz kodu ve ham verileri click2photon GitHub deposunda yayımlanmış durumda
Tıklamadan ekran değişimine kadar ölçen cihaz
- Cihaz monitöre takılıyor, USB üzerinden fare tıklaması üretiyor ve optik sensör ekran değişimini algılayana kadar geçen süreyi ölçerek uçtan uca sistem gecikmesini ölçüyor
- İlk tasarım, o dönem erişilebilir olan OSLTT devre şemasını temel aldı; tamamlanma sürecinde m2p-latency ve Open-Source-LDAT fikirleri de entegre edildi
- Yapım için mikrodenetleyici, lehimleme, Arduino firmware’i, entegrasyon süresi, transimpedans yükselteci, KiCad ve muhafaza tasarımı gerekti
- Adafruit QT Py RP2040, 1.000Hz polling yapan USB HID fare gibi çalışarak tıklama üretiyor
- Tıklama gönderiminin hemen ardından yaklaşık her 24µs’de bir fotodiyot örneği topluyor
- Her tıklama için 12.000 örneği seri bağlantı üzerinden host’a gönderip CSV olarak kaydediyor
- Host aracı, her tıklama için baseline’ı hesaplıyor ve baseline’dan belirli bir seviyenin üzerinde sapan ilk örneği buluyor
- 12.000 örneğin toplanma süresi sabit olduğundan, tıklama gönderiminden ekran parlaklığı değişimine kadar geçen süre hesaplanabiliyor
Karşılaştırılan görüntü ve render yapılandırmaları
- Wayland’in hissedilir biçimde yavaş olduğu yönündeki değerlendirmeyi ölçüm sonuçlarıyla karşılaştırmak için X11 ve yerel Wayland kıyaslandı
- G-Sync ve FreeSync’i de kapsayan değişken yenileme hızı (VRR) özelliğinin açık/kapalı durumu karşılaştırıldı
- dxvk-low-latency ile varsayılan DXVK arasındaki fark ölçüldü
- Bu fork’un frame pacer’ı resmi
proton-cachyos paketine entegre edildi ve PROTON_DXVK_LOWLATENCY=1 ile etkinleştiriliyor
- Frame pacer’ın frame time dalgalanmalarını sönümleyip render kuyruğu birikmesini önleyip önlemediğini görmek için FPS sınırı kaldırılmış 2 senaryo eklendi
- Statik oyun sahnesinde frame time dalgalanması yoktu ve test de CPU darboğazı koşulundaydı; bu nedenle gerçek oyun oturumlarını tam olarak yansıtmıyor
- Gerçek oturumlarda oyun içi durumlara veya başka süreçlerin kaynak kullanımına bağlı olarak frame time değişebilir
- Wayland testleri temelde
PROTON_ENABLE_WAYLAND=1 kullanan yerel Wayland’de çalıştırıldı; karşılaştırma için VRR kapalı XWayland senaryolarından 2 tane de ölçüldü
Test donanımı ve yazılımı
- Test sırasında yalnızca tek bir ekran bağlıydı; donanım yapılandırması şöyleydi
- AMD Ryzen 7 5800X3D
- NVIDIA GeForce RTX 4070 SUPER
- DDR4 3.200MHz 8GB modül 2 adet
- MSI MAG 272QP QD-OLED X50, 2560×1440, 500Hz
- MSI B450 GAMING PRO CARBON AC
- Yazılım yığını CachyOS, Kernel 7.1.3-2-cachyos, NVIDIA driver 610.43.03-1, KDE Plasma 6.7.2-1.1, xorg-server 21.1.24-1.1 bileşenlerinden oluştu
proton-cachyos-native 1:11.0.20260602-3 ve dxvk 3.0 kullanıldı- CachyOS varsayılan kernel scheduler’ı korundu
Ekran ve DXVK ayarları
- Sistem yenileme hızı 500Hz olarak ayarlandı
- X11’de
nvidia-settings ile flip mode ve VRR etkinleştirildi; VRR değişikliği için yeniden başlatma gerekiyor
- Wayland’de VRR, KDE ayarlarıyla etkinleştiriliyor ve yeniden başlatma gerekmiyor
- Wayland’de flip mode veya direct scanout kullanıcı tarafından doğrudan ayarlanmıyor; compositor bunu kare bazında belirliyor
- KWin Debug Console’un Effects sekmesinde
showcompositing etkinleştirildi
- Yalnızca oyun tam ekranda gösterildiğinde, tamamen odaktayken ve kenarlarda kırmızı çerçeve yoksa flip mode olarak değerlendirildi
- Karşılaştırma koşullarına göre optimize edilmiş
dxvk.conf kullanıldı
- VRR devre dışıyken
dxgi.maxFrameRate = 500
- VRR etkinken ve dxvk-low-latency devre dışıyken
dxgi.maxFrameRate = 497
- VRR ile dxvk-low-latency birlikte etkinleştirildiğinde, 500Hz için düşük gecikmeli VRR frame pacing aşağıdaki ayarlarla kullanıldı
dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
- Tüm yapılandırmalarda
d3d11.cachedDynamicResources = "c" uygulandı
Oyun ortamı ve tekrarlı ölçüm prosedürü
- Test oyunu, Heroic ve Proton ile çalıştırılan DirectX 11 oyunu Diabotical
- Yerel çözünürlük ve %100 render ölçeği kullanıldı, Vsync kapatıldı ve diğer görüntü ayarları mümkün olduğunca düşürüldü
- Arayüzü kısa süreliğine gizleyen gizli komut
/bind mouse_left testlatency ile sol tıklamaya bağlandı; tıklama anında parlaklık farkını büyütmek için büyük beyaz bir kutu gösteren HUD yapılandırıldı
- Her test aynı koşullarda tekrarlandı
- Gereksiz yazılımlar kapatıldı ve aynı mod ile haritada yerel sunucu başlatıldı
- Belirlenen konumda fare belirli bir arazi işaretine hizalandı
- Yaklaşık 2 dakika boyunca 100 kez tıklama süreci toplam 3 kez tekrarlandı
- Bot, başka oyuncu, hareket veya round yeniden başlatma olmadan statik sahne korundu
- Anlamlı başka süreçlerin çalışmaması sağlandı ve ölçüm cihazının konumu da tüm testlerde sabit tutuldu
Tüm yapılandırmaların gecikme aralığı
- Kare sınırlaması uygulanan tüm senaryolar hedef FPS’i kararlı biçimde korudu ve oyun test boyunca CPU darboğazı durumundaydı
- Tüm senaryolar büyük aykırı değerler olmadan çan eğrisi benzeri dağılım gösterdi; p5’ten p95’e genişlik yaklaşık 2~3ms idi
- Başlıca 8 yapılandırmanın medyanı 4,21~4,93ms oldu; toplam fark yalnızca 0,72ms idi
- XWayland, karşılık gelen yerel Wayland yapılandırmasına göre medyanı en fazla 3,13ms yükseltti; değerler sırasıyla 8,06ms ve 4,93ms idi
- FPS sınırı kaldırılan senaryoda dxvk-low-latency, varsayılan DXVK’ya göre gecikmeyi 0,84ms azalttı
X11 ve yerel Wayland arasındaki küçük fark
- X11 tüm yapılandırmalarda daha hızlıydı; ancak fark 0,14~0,22ms ile küçüktü ve Wayland’in çok daha yavaş hissettirdiği değerlendirmesini açıklamak için yetersizdi
- low-latency ve VRR etkin: X11 4,21ms, Wayland 4,38ms, fark +0,17ms
- yalnızca low-latency etkin: X11 4,64ms, Wayland 4,83ms, fark +0,19ms
- yalnızca VRR etkin: X11 4,45ms, Wayland 4,67ms, fark +0,22ms
- ikisi de devre dışı: X11 4,79ms, Wayland 4,93ms, fark +0,14ms
- İki görüntü sunucusunun gecikme dağılımı şekli de birbirine çok benziyordu
VRR’nin gecikme ve dağılıma etkisi
- VRR, karşılaştırma kalemleri arasında en büyük etkiyi gösterdi ve tüm kombinasyonlarda 0,26~0,45ms daha hızlıydı
- X11 ve low-latency: 4,64ms’den 4,21ms’ye inerek 0,43ms azaldı
- X11 varsayılan DXVK: 4,79ms’den 4,45ms’ye inerek 0,34ms azaldı
- Wayland ve low-latency: 4,83ms’den 4,38ms’ye inerek 0,45ms azaldı
- Wayland varsayılan DXVK: 4,93ms’den 4,67ms’ye inerek 0,26ms azaldı
- p95 ile p5 arasındaki genişlik VRR kullanıldığında 2,1~2,2ms, kullanılmadığında 2,6~3,0ms çıktı; gecikme dağılımı da daraldı
- VRR’de kareler bir sonraki scanout slotunu beklemeden hazır olur olmaz scanout edildiği için ölçüm sonuçları çalışma biçimiyle örtüşüyor
dxvk-low-latency’nin etkisi ve maliyeti
- FPS sınırlı senaryolarda dxvk-low-latency tüm kombinasyonlarda gecikmeyi azalttı; ortalama iyileşme 0,20ms olup X11 ile Wayland arasındaki ortalama 0,18ms farka benziyordu
- X11 ve VRR: 4,45ms’den 4,21ms’ye inerek 0,24ms azaldı
- X11 ve VRR devre dışı: 4,79ms’den 4,64ms’ye inerek 0,15ms azaldı
- Wayland ve VRR: 4,67ms’den 4,38ms’ye inerek 0,29ms azaldı
- Wayland ve VRR devre dışı: 4,93ms’den 4,83ms’ye inerek 0,10ms azaldı
- FPS sınırı kaldırılmış koşulda pacer’ın render kuyruğu birikmesini engelleme ve düzensiz frame pacing’i yumuşatma etkisi daha belirgin görüldü
- GPU’yu tamamen doyurmadan GPU darboğazına yakın durumda tuttu
- GPU kullanımı varsayılan DXVK’da %100, dxvk-low-latency’de %95~97 idi
- Gecikme 5,27ms’den 4,43ms’ye inerek 0,84ms azaldı
- FPS 715’ten 670’e düşerek 45FPS azaldı
XWayland’in eklediği büyük gecikme
- Heroic Launcher’daki
Enable Wine-Wayland (Experimental) veya PROTON_ENABLE_WAYLAND=1 kapatıldığında oyun XWayland üzerinden çalışıyor
- XWayland, yerel Wayland’e göre büyük gecikme ekliyor
- low-latency etkin: 4,83ms’den 5,95ms’ye çıkarak 1,12ms arttı
- varsayılan DXVK: 4,93ms’den 8,06ms’ye çıkarak 3,13ms arttı
- Varsayılan DXVK’da eklenen 3,13ms, ölçülen diğer tüm etkilerin toplamından daha büyüktü; bu, birkaç kötü karenin ortalamayı yükseltmesi değil, tüm dağılımın kaymasıydı
- XWayland’de dxvk-low-latency eklemek gecikmeyi 2,11ms azaltarak tüm senaryolar içindeki en büyük iyileşmeyi kaydetti
Sonuçların kapsamı ve pratik yorum
- Ölçüm sonuçları, kararlı sınırlı FPS, CPU darboğazı ve statik sahne gibi ideal koşullarla ve belirli bir donanım-yazılım yığınıyla sınırlıdır
- Başka ortamlarda mutlak gecikme değerleri değişebilir; ancak her yapılandırmada oluşan artış/azalışların büyük ölçüde taşınabileceği düşünülüyor
- Yenileme hızı daha düşük ekranlarda VRR ve düşük gecikmeli pacer’ın iyileştirme payının daha büyük olma ihtimali var
- X11, Wayland’den 0,14~0,22ms daha hızlıydı; ancak KWin optimizasyon çalışmalarıyla fark daralabilir ve diğer Wayland compositor’larının hâlihazırda daha iyi olma ihtimali de açık
- XWayland hariç tutulduğunda, X11·VRR·dxvk-low-latency’nin tümü uygulanırsa varsayılan Wayland yapılandırmasına göre medyan 0,72ms daha düşük oluyor
- Medyan farkı küçük olsa da VRR gecikme jitter’ını azaltıyor; dxvk-low-latency ise gerçek oyunlarda görülen frame time düşüşlerini ve GPU darboğazı durumlarını hafifletiyor
Benzer giriş gecikmesi ölçüm projeleri
1 yorum
Hacker News yorumları
Linux’un iyi yanı, bu tür analizlerin yalnızca mümkün olması değil, gerçekten ekosistem iyileştirmelerine dönüşebilmesi. Sonuçlar grafik yazılımı geliştiricilerine ve dağıtım paket yöneticilerine ulaştırılıyor; Microsoft tarafında ise böyle bir iyileştirme yolunu beklemek zor görünüyor.
Uzun süre Windows kullandıktan sonra yakın zamanda Linux’a geçtim; KDE Plasma’nın Windows 11’den daha çevik hissettirmesini ve bir sorun çıktığında doğrudan müdahale edip iyileştirebilmeyi sevdim. Bir süredir Linux masaüstü denemediyseniz, oyun için ayarlanmış Fedora olan Bazzite’ı öneririm; oyun oynamasanız bile hızlıca olgun bir masaüstü kurabiliyorsunuz.
Eskiden sezgisel tek bir yapılandırma dosyasıyla istediğiniz gibi değiştirebiliyordunuz; şimdi ise tema, ikon, açık mod, koyu mod üzerine sayısız soyutlama katmanı çıkmış olsa da düzgün çalışan bir kombinasyon bulmak zor. Açık modda açık gri üstünde gri yazı, koyu modda siyah arka plan üstünde siyah yazı görünüyor; Adwaita gibi temalara bağlı olarak PDF görüntüleyiciler bile metin ve arka plan rengini doğru belirleyemeyebiliyor.
Hiçbir tema kaydırma çubuklarını yeterince görünür yapmıyor, etkin pencere ile etkin olmayan pencereyi de net renklerle ayırmıyor. Windows 3.11 bile kaydırma çubuklarını, etkin pencere göstergesini ve renk özelleştirmesini daha iyi yapıyordu; aşırı tasarlanmadan önceki hâli aslında daha iyiydi.
Intel(https://www.techpowerup.com/312122/psa-intel-graphics-driver...) ve Nvidia(https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) da onay veren kullanıcılardan bu tür verileri topluyor. Ancak ikisi de isteğe bağlı katılım modeli kullandığından, tutkulu oyunculardan gelen veri çok fazla olmayabilir.
Kademeli değişim çok olsa da yıllarca yerel optimumlarda takılı kalınabiliyor. Yine de iç işleyişi görece kolay inceleyebilmek iyi; Windows ve macOS’un neden mutlaka kapalı kaynak olması gerektiğini pek anlayamıyorum.
Birkaç ay önce ana işletim sistemimi ve oyun ortamımı Fedora olarak değiştirdim; genel olarak Windows’tan daha çevik hissettirdi ve bu ölçüm oyunlardaki giriş gecikmesine dair merakımı kısmen giderdi.
Yakın zamanda Wayland tabanlı Hyprland’e geçtim; sonuçların nasıl değişeceğini merak ediyorum ve popülerliği arttığı için yeniden test edilmesi güzel olurdu. Gamescope’u da düşündüm ama Nvidia’da iyi çalışmadığı söyleniyor; oyun için optimize edilmiş kernel diye bir şey olduğunu da ilk kez öğrendim. Rekabetçi dövüş oyunlarında giriş gecikmesi çok önemli, bu yüzden benzer optimizasyonlar denemiş kişilerin deneyimlerini duymak isterim.
Oyunlarda Hyprland’i beğendim; X11’de AwesomeWM kullanırken olduğundan, Gamescope üzerinden değişken yenileme hızı ve tearing gibi ince ayarları yapmak daha kolaydı. Lua yapılandırması da AwesomeWM kullanmış biri olarak tanıdık geldi.
Testler 500 Hz ekran ile yapıldığı için düşük yenileme hızlı ekranlarda ortaya çıkacak birçok sorun gizlenmiş olabilir. XWayland’in 3 ms daha yavaş olması, bu yenileme hızında bir kare geride kalmış olabileceği anlamına da gelebilir.
120 Hz ya da 60 Hz ile test edilirse, yürütme zamanlamasındaki ince farklar ile tam bir karenin gecikmesi gibi büyük etkiler daha net ayırt edilebilir.
Yazının sonunda Wayland’ın neden yavaş sanıldığını anlamakta zorlanıyor, ancak XWayland sonuçları bunun nedeni olabilir. Wayland üzerinde X11 oyunları çalıştıran kullanıcıların anlamlı bir gecikme hissetmiş olması mümkün. Farklı alanlarda bu tür gerçek ölçümlerin daha fazla yapılması iyi olurdu
Yazar diğer karıştırıcı değişkenleri iyi elemiş, ancak Wayland’ın yavaş olduğunu hisseden kullanıcılar optimize edilmemiş bir ortamdan başlayıp düşük gecikmeli bir yapılandırmaya geçerken ilgili ayarları da aynı anda düzeltmiş olabilir
Her yerde fiilî standart referans uygulaması olan Xorg’un benzer davrandığı X11’in aksine, Wayland uygulamaları arasındaki farklar büyük. Testte kullanılan KDE Plasma’dan daha yavaş compositor’lar da, daha hızlı compositor’lar da olabilir
Wayland giriş gecikmesi ifadesinin kendisi,
HTTP animasyon akıcılığıgibi farklı katmanları birbirine karıştıran bir söz. Bu yazının ölçtüğü şey Xorg, KWin ve XWayland; diğer X11 ve Wayland uygulamalarının özellikleri farklı olabilirYine de XWayland’ın ek gecikmesi, basit bir ek maliyet diye geçiştirilemeyecek kadar şüpheli biçimde büyük
Özellikle pgtk modundaki Emacs, GNOME’da çok daha iyi çalışıyor; KWin’de ise kaydırma yaparken CPU’yu çok kullanıyor ve yüksek çözünürlükte biraz gecikebiliyor
Aynı donanımda Windows ile karşılaştırıldığında nasıl sonuç vereceği de çok ilginç olurdu
Breaka Club’da, modifiye edilmiş Overcooked 2! ile çocuklara kodlama öğretirken bu sorunu doğrudan ele alıyoruz
Okul cihazlarına mod kurmak zor olduğu için mod içeren OC2’yi WebRTC ile stream ediyoruz; çocuklar da iPad’de Mobile Safari üzerinden ekrandaki gamepad ile oynuyor. Oyun instance’ları eski Nvidia donanımı üzerinde Kubernetes/k3s içindeki Docker container’larında çalışıyor; internet ve okul ağından geçtiği için toplam gecikmeyi azaltmak amacıyla NVEnc ve DMABuf ile sıfır kopyalı aktarım gibi yöntemler kullanıyoruz
Şu anda XWayland’ın giriş ek maliyetini yaşıyoruz, ancak giriş sanal aygıt olduğu için durum farklı olabilir. Uçtan uca optimizasyon zor ve mevcut performans kabul edilebilir düzeyde. OC2 kodlama videosu: https://www.youtube.com/watch?v=ITWSL5lTLig
OC2 lisanslarını sınırlı sayıda satın aldık; bir pod başlatıldığında bunlardan birini alıyor, hepsi kullanımdayken çocuklar başka bir oyun oynuyor
X11’de bileşik işleme kullanırken tam ekran bir pencere compositor’a yönlendirmeyi kaldırma ipucu gönderirse, ekrana başka öğeler çizilmediği sürece bileşik işlem durdurulup uygulamanın swapchain’i doğrudan ekrana iletilebilir. Bu fiilen en iyi yöntemdir, dolayısıyla daha fazla iyileştirmek zordur
Üste başka bir pencere geldiğinde veya compositor doğrudan iletim yapamayacağına karar verdiğinde, uygulama penceresiyle diğer öğeleri geçici bir buffer’da birleştiren bir ara aşama oluşur. Pencerenin ekran yüksekliğinden 1 piksel küçük oluşturulması gibi yönlendirmeyi kaldırmayı bozan durumlarda ya da XWayland kullanıldığında gecikme artabilir; bu temel bir kısıttır ve diğer işletim sistemlerinin compositor’larında da benzer sorunlar ortaya çıkar
Wayland, GPU donanımının birden fazla katmanı doğrudan birleştirdiği görüntü düzlemlerini (display planes) de araştırdı. Bunlar kullanılırsa oyun en yüksek FPS ile render ederken üstteki pencere ayrı bir düzleme çizilip yan etki olmadan birleştirilebilir; ancak bunun gerçek ürün ortamlarında kullanılıp kullanılmadığını bilmiyorum
Konsollar sabit bir çıktı kare/saniye değeri ve dinamik çözünürlüğü hedeflerken, PC’ler çözünürlüğü sabit tutup kare/saniye ve kare zaman aralıklarını dinamik bırakma eğiliminde. Bunun gecikmeyle nasıl ilişkili olduğunu merak ediyorum
Özellikle rekabetçi oyunlarda ekran yenileme hızının çok üstünde kare/saniye hedefleniyor; bunun gerçekten avantaj mı, yoksa bir yanılgı mı olduğundan emin değilim
Esas mesele daha fazla kare görmek değil, daha güncel bilgi görmek. Render işlemini ekran yenilemesinin hemen öncesinde bitecek şekilde geç başlatmak da mümkün; ancak zamanlamayı azıcık kaçırırsanız ciddi takılma olur ve GPU çalışma süresi ile CPU’nun iş gönderme süresi deterministik değildir
İdeal olarak gereksiz kareler üretmeden, ekran yenilemesinin hemen öncesinde render etmeye başlamak yeterli olurdu; fakat son teslim anını kaçırırsanız çok rahatsız edici takılmalar oluşur
Yeni bir kare ekran tarama sürecinin ortasına girebilir ve bu da tearing oluşturur; ancak sınır çizgisinin altında daha güncel pikseller gösterilir. Bu yüzden bir monitörün tek karesine birden fazla render karesi karışabilir ve yüksek yenileme hızlı değişken yenileme oranlı bir ekran kadar iyi olmasa da gecikmeyi azaltır. Hareketin daha az önemli olduğu oyunlarda VSync ile kareleri yenileme hızına uydurup tearing’i ortadan kaldırmak yaygındır
Bazı oyunlar sabit kare/saniye için çözünürlüğü gerçek zamanlı ayarlar. PC’de oyunlar zaten hedeflenenden çok daha düşük donanımlarda çalıştırılabiliyordu, düşük kare/saniye kültürel olarak daha kabul edilebilirdi ve isterseniz yükseltme yapabilirdiniz. Konsollarda yükseltme yolu yoktur ve tek bir yapılandırma için optimize etmek gerekir; bu yüzden performans çok düşmeden önce çözünürlüğü düşürme yöntemi daha uygundu
Bu, oyunun daha fazla giriş olayı aldığı anlamına gelmez; ancak girdiyi daha hızlı işleyip yansıtabilir. Yanılgı değildir, ama getirisi hızla azalır; etkisi kare kuyruğu, VSync, değişken yenileme oranı, CPU veya GPU darboğazı, giriş ve simülasyon döngüsünün yapısına göre değişir
Yazar baştan itibaren yanılgıyı dışarıda bırakmaya çalışıyor, ama gecikme sonuçta his ve kullanım deneyimiyle değerlendirilen bir şey değil mi diye düşünüyorum. Kişisel olarak nasıl hissettirdiği nihai testtir; gerçek gecikmeyi teşhis edip düzeltmede veriler yararlı olsa da çoğu UI/UX bağlamında tercih ve hissiyata dayanmakta sorun olmadığını düşünüyorum
Yıldız puanı gibi daha az teknik değerlendirmeleri birlikte kullanmak, test ve veri toplamanın yöntembilime aşırı saplanmasını da engelleyebilir. Titizlikle kurgulanmış testlerde, belirli bir ortamın günlük kullanımında sık görülen performans düşüşü koşulları dışarıda kalabilir