Prostudoval jsem si článek na PC Perspective natolik, abych pochopil, oč jde. Dokonce jsem zkoumal i naměřené výsledky přímo v základu, tedy v ukázkových vystavených XLS souborech, které jsou výstupy nástroje Extractor. V nich jsem se však nedopočítal stejných výsledků jako samotný Extractor, který kromě délky pruhu rovnou vypočítává i dobu snímku, přepočet na fps a podobně. Názorná ukázka:

20130214152121_HD7970CrossFire_BF3_2560x1440.xls (zdroj dat: PC Perspective)

Nyní jsem zkombinoval trochu jednoduché matematiky s trochou logického uvažování (nevylučuji, že mi to vynechává, tak mě když tak opravte): jak se spočítá, jak dlouho snímek trval? Dejme tomu, že:

• máme rozlišení 2560×1440 (uvedeno v záhlaví dokumentu, takže v tomto rozlišení se testovalo), tj. máme 1440 řádků (neboli počet scanlines per screen ref…),
• máme zobrazovací frekvenci 60 Hz

Základní otázka: jak dlouho trvá snímek, který akorát vykryje jednu obrazovku? Při 60Hz zobrazování je to samozřejmě 1/60 sekundy, neboli 16,66… ms. Takový snímek bude mít svůj barevný pruh vysoký právě 1440 bodů (scanlines). Tak tedy:

Jak dlouho trvá snímek č. 0 na 2. řádku, který bude mít 988 bodů? Poměrnou část ze 1440. jinými slovy 1/60 sekundy vynásobíme poměrem pruhu (tedy 988/1440). Ať počítám, jak počítám, dostávám číslo 11,435185… ms. Jak to, že je v dokumentu 11,125881…? Já vím, rozdíl je to malý, ale ono to pak místo 89,88 fps udělá 87,45 fps.

Jak dlouho trvá snímek č. 5 na 7. řádku, který vygeneroval cosi jako microstuttering, neboť se projevil jen na 6 řádcích ze 1440? Podle údajů v souboru 0,067566… ms, podle mých výpočtů 0,06944… ms. Čert to vem, tenhle snímek je prostě pořád microstutterový.

No a konečně jak dlouho trvá snímek č. 8 na 10. řádku, který má 1440 bodů na výšku? Bystřejší z vás již vědí, že o tomto snímku jsme již hovořili. Je to kompletní snímek a trvá 1/60 sekundy. V souboru je u něj ale uvedeno něco jiného. Takovéto snímky by měly dávat přesně 60 fps, v souboru je ale neochvějně zmíněno 61,668… fps.

Vysvětlení lze vyčíst i z této malé ukázky: spočítejte si řádky barevných pruhů (scanlines) vs. obnovení obrazovky (screen ref…). Do všech screen ref (které jsou na screenshotu vidět) se vejde překvapivě celých 1480 řádků. To je při rozměru obrazu 2560×1440 bodů trošku moc, ne? ;-) Je to zajímavé, vždy přebývá 40 řádků. A když se dobře podíváte do toho dokumentu, zjistíte, že těch 40 řádků je vždy na konci každého snímku a pruh k nim asociovaný je vždy černý (doufám, že tohle čtou ostřílení profíci, kteří už také nevidí kód, ale prostě bloncku, brunetu, zrzku… ;-).

Když už se koukáme přímo na barvy a ne na kód, pak zrovna onen zmíněný 8. snímek na 10. řádku ve skutečnosti pokračuje jako snímek 10 na 12. řádku. Jak se to pozná? Snadno: Vynecháme 9. pseudosnímek s černým pruhem a koukneme se na 10. snímek. Jakou barvu má jeho pruh? Na první pohled jinou, ale na druhý pohled – ano, mezi  #FBFBFB  a  #FCFBFB  je skutečně jen kosmetický rozdíl. Tyhle dva kusy snímku ve skutečnosti tvoří jeden snímek.

Teď jen „doufám“, že ta sada analyzačních nástrojů udělaných v Perlu o těchto chybách neví a je o zábavu postaráno ;-).

Doplněno 22:53: Díky čtenářům, jmenovitě „Suchému čertovi“ za objasnění problematiky. Černé 40pixelové meziproužky jsou zjevně simulace vertikálních „zatemňovacích“ intervalů, které se do času nutného k zobrazení též připočítávají. Perlové skripty na jejich přítomnost spoléhají a počítají s nimi. V Extractoru tedy bug není. Je to vlastnost :).