Frame-skippingtest

Zo gebruik je deze test

1. Klik op Test starten en laat de test kalibreren.

   De eerste seconde of zo bepaalt automatisch je echte verversingsinterval — je hoeft de Hz van je monitor niet in te voeren.

2. Laat de test minstens 15-30 seconden draaien.

   Een korte run kan door puur toeval nul skips laten zien; langere runs geven een eerlijker beeld.

3. Let op pieken in de live grafiek.

   Een vlakke lijn rond je verwachte frametijd is gezond; hoge pieken zijn skips die op het moment zelf worden opgevangen.

4. Sluit andere tabbladen en zware programma's als er vaak skips zijn.

   Deze test ziet alleen vertragingen aan de kant van de browser — een zwaar belast systeem is een veelvoorkomende, oplosbare oorzaak.

5. Gebruik een camera voor bevestiging op paneelniveau.

   Ziet deze test er goed uit maar voelt beweging toch niet soepel, dan laat een foto met lange sluitertijd van de marker zien hoe het scherm zelf frames aflevert — iets wat deze test niet kan zien.

1%-lows en haperingsritme: wat de extra cijfers je vertellen

Onder de grafiek staan drie waarden die een eenvoudige skipteller je niet geeft. De gemiddelde fps is het getal waar de meeste tools stoppen, en het verbergt bijna alles wat interessant is. De 1%-low is de gemiddelde framerate van de langzaamste 1% van de frames en de 0,1%-low is hetzelfde voor de langzaamste van duizend. Op een gezond 60Hz-scherm liggen alle drie binnen een paar procent van elkaar. Zegt het gemiddelde 59,8 maar de 1%-low 31, dan hangt het scherm om de paar seconden een frame of twee, en is het gemiddelde simpelweg een te grote menigte om dat te laten zien.

Het derde onderdeel is het haperingsritme. Elke keer dat een frame te laat komt, noteert de test wanneer dat gebeurde en kijkt daarna naar de tussenpozen tussen de haperingen. Tussenpozen die steeds ongeveer even groot zijn (zeg 4,0 s, 4,1 s, 3,9 s) wijzen op iets dat op een timer draait: een synchronisatieclient, een geplande scan, een RGB- of monitoringtool die de hardware uitleest, een energiebesparingsstand die inschakelt. Tussenpozen die overal liggen betekenen meestal gewoon belasting. De staafgrafiek voegt nog iets toe: frames die te laat waren, maar niet laat genoeg om als skip te tellen (1,25 tot 1,5 keer het normale interval). Een lange reeks daarvan voelt als zachte judder, ook als de skipteller op nul staat.

Zo gebruik je het: sluit wat je kunt, druk op „Test starten”, laat het tabblad zichtbaar en blijf eraf, en laat de test minstens 20 seconden draaien (een minuut is beter). Druk op „Test stoppen”. De oordeelregel vat de run dan samen. Voor de 1%-low zijn ongeveer 100 frames nodig, voor de 0,1%-low ongeveer 1.000 (grofweg 17 seconden bij 60 Hz, 7 bij 144 Hz), en voor de ritmecontrole zijn minstens vier haperingen nodig voordat hij iets zegt. Draai de test daarna opnieuw met een verdacht programma gesloten. Verdwijnt het ritme, dan heb je je timer gevonden.

De beperkingen zijn dezelfde als voor de rest van deze pagina. Hij ziet wat de browser heeft kunnen tekenen, niet wat het paneel daarna deed. Frametijdstempels zijn zo nauwkeurig als je browser ze doorgeeft, dus verschillen van een milliseconde of zo betekenen niets. En een haperingsritme zegt dat iets periodiek is, niet wat het is. Dat is speurwerk met Taakbeheer of Activiteitenweergave.

Frame-skipping op een 60 Hz-scherm: een resultaat van 30 seconden lezen

Stel dat je de test 30 seconden draait op een scherm van 60 Hz. De gedetecteerde snelheid is 60 Hz, dus een normaal frame duurt ongeveer 16,7 ms. Als je op “Test stoppen” klikt, staat er in de statusregel: “18 skip(s) gedetecteerd in 1782 frames (1.01%). Langste hapering: 66.7 ms.” 66,7 ms is vier normale intervallen, dus elke lange hapering kostte drie frames. Het oordeel voegt toe “Het gemiddelde (59 fps) ziet er goed uit, maar de 1%-low is 30 fps. Dat verschil is zichtbare haperingen.” en de ritmeregel luidt “Haperingsritme: regelmatig. Ongeveer één hapering per 5.0 s (grofweg om de 300 frames) over 6 haperingen. Dat lijkt op iets dat op een timer draait.” Zes haperingen van elk drie verloren frames, daar komen de 18 vandaan.

Een hapering die precies elke vijf seconden terugkomt, is meestal een timer. Stel dat je Taakbeheer opent en daar een cloudsyncprogramma vindt dat elke vijf seconden wakker wordt. Je pauzeert het en draait de test nog eens 30 seconden. Nu staat er in de statusregel “Geen skips gedetecteerd in 1800 frames” en het oordeel begint met “Soepel.”, met een 1%-low binnen 10% van het gemiddelde. Zelfde scherm, zelfde browser, één achtergrondprogramma minder.

Niet elke skip is een probleem. Stel dat een run “1 skip(s) gedetecteerd in 1800 frames (0.06%). Langste hapering: 33.3 ms.” laat zien en het oordeel zegt “Grotendeels stabiel. 1%-low 57 fps tegenover een gemiddelde van 60 fps, met 1 skip.” Dat is één gemist frame in een halve minuut, waarschijnlijk door het wisselen van venster of doordat de pagina net de laatste bestanden laadde toen je op “Test starten” drukte. Draai de test opnieuw zonder iets aan te raken. Komt hij schoon terug, dan kun je het negeren.

Hoe deze test echt werkt

Elke aanroep van requestAnimationFrame geeft een tijdstempel terug, en deze test meet het verschil tussen opeenvolgende tijdstempels in plaats van uit te gaan van een vast getal. Bij de eerste paar dozijn frames verzamelt hij die tussenpozen en neemt hij de mediaan om je echte verversingsinterval vast te stellen — ongeveer 16,7ms op een scherm van 60Hz, 6,9ms op 144Hz, enzovoort — en daarom werkt hij hetzelfde, ongeacht de specificaties van je monitor, zonder dat je iets hoeft in te voeren.

Na dat kalibratievenster wordt elk tijdsverschil dat merkbaar langer is dan het verwachte interval — meer dan 1,5 keer zo lang — als skip geregistreerd, en het aantal overgeslagen frames wordt berekend uit hoeveel langer dat tijdsverschil was dan verwacht. De genummerde marker hierboven gaat bij elk frame dat de browser echt rendert één omhoog, en dat maakt fotograferen zinvol: een echte skip verschijnt als een herhaald of ontbrekend nummer, niet zomaar als een nummer op een scherm.

Wat deze test niet kan zien

Hier zijn we liever eerlijk over, in plaats van de tool meer te laten beloven dan hij kan waarmaken. Een hier getelde frame-skip betekent dat de browser zelf er niet in slaagde op tijd een nieuw frame aan het scherm af te leveren — meestal omdat de hoofdthread met iets anders bezig was en zijn moment miste. Dat is een echte, veelvoorkomende oorzaak van zichtbaar haperen, en precies het soort uitval waarvoor deze test is gebouwd.

Wat hij niet kan zien is frame-skipping die verderop in de keten gebeurt, in de monitor zelf. De eigen scaler van een paneel kan stilletjes een frame herhalen dat de browser perfect en op tijd had aangeleverd — vanuit de browser gezien ging er helemaal niets mis, en toch hapert het scherm. Geen enkele hoeveelheid JavaScript in een browsertabblad kan dat waarnemen, want op het moment dat zo'n skip gebeurt, heeft de browser zijn werk al gedaan.

Skippen op paneelniveau bevestigen met een camera

De praktische manier om te controleren wat je monitor echt doet, los van wat deze test meldt, is een foto met lange sluitertijd. Stel de sluitertijd van een telefooncamera langzamer in dan één verversingsinterval — bij een scherm van 60Hz langzamer dan ongeveer 1/60e seconde — en fotografeer de genummerde marker terwijl de test draait.

Gelijkmatig verdeelde, duidelijke nummers in de resulterende streep betekenen dat het paneel frames met een constante cadans toont. Een gat waar een nummer hoort te staan, of hetzelfde nummer dat twee keer verschijnt, wijst erop dat het paneel zelf een frame overslaat of herhaalt — een probleem op hardwareniveau dat deze teller aan de browserkant zelf niet kan opvangen.

Wat frame-skipping veroorzaakt

Aan de kant van de browser: een processor die met iets anders bezig is, achtergrondtabbladen of -programma's die om systeembronnen concurreren, een garbage-collectionpauze die de hoofdthread even stillegt, of een gpu die achterloopt met compositing — een verouderd grafisch stuurprogramma maakt dat laatste waarschijnlijker, dus controleer of je de nieuwste versie hebt van NVIDIA, AMD of Intel. Elk hiervan kan ervoor zorgen dat de browser zijn moment mist om een nieuw frame aan te leveren, wat deze test terecht opvangt.

Aan de kant van het scherm: een kabel of poort die je gekozen resolutie en verversingssnelheid niet samen volledig aankan (een veelvoorkomend voorbeeld is 4K op 120Hz via een poort die alleen 4K op 60Hz aankan, wat stilletjes kan terugvallen of skippen), een verversingssnelheid die verder is opgevoerd dan het paneel betrouwbaar kan volhouden, of agressieve beeldverwerking zoals bewegingsinterpolatie die de frametiming verstoort. Dit zijn de gevallen waarvoor je de cameramethode hierboven nodig hebt om ze echt te bevestigen — diezelfde verwerking is ook een veelvoorkomende oorzaak van de extra onscherpte waarop onze Ghostingtest controleert.

Deze test vs. de Verversingssnelheidtest

Deze twee beantwoorden verschillende vragen en vullen elkaar goed aan. De Verversingssnelheidtest vertelt je met welke snelheid je scherm nu werkt — doet het echt 144Hz, of is het stilletjes teruggevallen naar 60? Deze test gaat ervan uit dat de gedetecteerde snelheid klopt en vraagt in plaats daarvan of elk frame bij die snelheid ook echt op tijd aankomt, of dat sommige onderweg worden overgeslagen of herhaald. Een scherm kan voor de ene test slagen en voor de andere zakken.

Meer tools op ProDeviceTest

Framelevering is maar één onderdeel van de algehele bewegingskwaliteit. Deze tools dekken de rest.

• Verversingssnelheidtest — meet wat je scherm op dit moment echt uitstuurt
• Ghostingtest — controleer bewegingsonscherpte en nasleep met een bewegend object
• HDR-test — controleer HDR, breed kleurbereik en detail in schaduwen en highlights
• Alle beeldschermtests — de volledige categorie