Page 1 of 3

TestUFO Display Lag Test coming! (SMTT accurate)

Posted: 22 Nov 2016, 14:39
by Chief Blur Buster
I have discovered how to get same display lag measurement accuracy (as SMTT 2.0) but completely inside a web browser test!

NOTE: I have never used SMTT 2.0 and I don't have a copy of SMTT 2.0, but I know how the principle work, and I've found a way to eliminate the 1000fps requirement, while getting <1ms accuracy, requiring only refreshrate-framerate matched animation.

No app needed, no 1000fps needed, only requires framerate matching refresh rate, 100% doable as web browser animation.

As long as browser can sync framerate to refreshrate -- accurate refresh rate displayed in TestUFO.com -- it will work.

Animation is extremely different from any test patterns ever released by anyone.
Still requires photography capture & a CRT (or reference display), but capable of measuring input latency to <1ms in ideal conditions.

http://www.testufo.com display lag test coming in 2017.

Re: TestUFO Display Lag Test coming! (SMTT accurate)

Posted: 22 Nov 2016, 15:34
by sharknice
Nice! Can you also use this with a second LCD you know the display lag on and compare the difference?

Re: TestUFO Display Lag Test coming! (SMTT accurate)

Posted: 22 Nov 2016, 16:03
by Chief Blur Buster
sharknice wrote:Nice! Can you also use this with a second LCD you know the display lag on and compare the difference?
Yup.

If you've got an accurate reference measurement, it can be tested differentially.

Just subtract the reference lag of the reference display -- and you've got your lag measurement of the second display.

Re: TestUFO Display Lag Test coming! (SMTT accurate)

Posted: 22 Nov 2016, 16:07
by Sparky
Will this work if the reference display/CRT and the monitor under test have different refresh rates?

Re: TestUFO Display Lag Test coming! (SMTT accurate)

Posted: 22 Nov 2016, 16:11
by Chief Blur Buster
Same refresh rate. 60Hz vs 60Hz. Or 120Hz vs 120Hz. Mirrored output.

Ideally, you want a HDMI or DVI distribution unit (a properly-working HDMI or DVI splitter) to eliminate any potential computer-induced or software-cloning overhead in input lag measurements. Or DVI distribution unit. Or VGA Y-adaptor. Etc.

Yes, you can clone via graphics card instead. That will work -- with a few caveats. Potential lag differentials occur between graphics cards outputs, with some cards, on some systems. To test via cloning, you want to measure with the same output technology (two HDMIs or two DisplayPorts) to reduce the odds of this -- and then you also want to measure once, then measure again with the outputs swapped (swap the cables), to make sure there's no lag differential changes caused by differences between the outputs. In some cases, if there's a lag differential between two cloned outputs -- then swapping cables and measuring again, then averaging the two measurements -- works to fix any fixed-size GPU-cloning-related input lag differentials. Not all graphics cards have latency differences between the same output technologies (e.g. HDMI output #1 and HDMI output #2) in mirroring mode, so the cable-swap is simply a verification check of existence or absence of cloning-related-lag. Testing DisplayPort versus HDMI versus DVI versus VGA will yield output-technology latency differences, which are useful datapoints, but not necessarily for comparing displays, so you ideally want to test using two outputs of the same technology -- not mandatory, but it improves the accuracy of differential input lag tests.

Pretty much the same issue as SMTT 2.0 also has -- you have to mirror the same screen to both.

Re: TestUFO Display Lag Test coming! (SMTT accurate)

Posted: 01 Dec 2016, 22:19
by flood
pics?

afaik even if you specify the same refresh rate for crt/lcd, the actual values may be off by a tiny bit (i.e. their vblanks aren't synchronized)

whether this thing works depends on the how the os and graphics card handles stuff when cloning with the gpu

Re: TestUFO Display Lag Test coming! (SMTT accurate)

Posted: 01 Dec 2016, 23:34
by Chief Blur Buster
flood wrote:pics?
I'm keeping it top secret until launch of the new TestUFO Lag Test in 2017

Otherwise, people will infer ideas of how I'm pulling it off, and beat me to this motion test.
I want to be #1 for a millisecond-accurate browser-based lag differential test.

As long as your TestUFO browser passes the Frame Skipping Test (perfect browser vsync), then the TestUFO lag test is capable of SMTT-accuracy.
flood wrote:afaik even if you specify the same refresh rate for crt/lcd, the actual values may be off by a tiny bit (i.e. their vblanks aren't synchronized)

whether this thing works depends on the how the os and graphics card handles stuff when cloning with the gpu
That's why a splitter is recommended. Just like for SMTT 2.0

However, there's a simple SLR photography test (short exposure photograph with two identical monitors, identical firmwares, and identical settings, on specific tests such as TestUFO Flicker Test) that verifies correctness of Cloning accuracy to <1ms for the particular tested inputs. I will be publishing instructions, for people who want to use Clone Mode instead of a simple splitter. That said, a splitter is obviously preferred since you don't have to wonder about scan sync. Once verified, Clone Mode can be used for either SMTT 2.0 or the TestUFO Lag Test. The clone sync issue is identical regardless of which Lag Test you use, but verifying clone accuracy is simple with a good short-exposure-capable SLR if you have two identical monitors for a clone sync verification. Accuracy of a sync check is better when holding the SLR upsidedown, due to rolling-shutter camera sensor scan direction opposite the display scan direction. (You'd be surprised at how rolling shutters interfere with the accuracy of SMTT 2.0... even a 1/1000sec shutter often scans in a 1/250sec top-to-bottom scan in a rolling shutter). There's clever tests to compensate for rolling-scan error in lag tests, and still get millisecond accuracy, but I'll keep quiet on rolling-shutter-error-compensation on these till the release, lest explaining how to compensate for rolling-scan-error reveals too much info on how I'm pulling this all off...

Also both SMTT 2.0 and the new TestUFO lag pattern equally require non-strobed-mode in order to be millisecond (or better ;) ) accurate.

Re: TestUFO Display Lag Test coming! (SMTT accurate)

Posted: 03 Dec 2016, 04:03
by ToastyX
I also have my own idea of how to make a more accurate lag tester, but mine wouldn't be browser-based. Browsers can't synchronize with multiple monitors, and desktop composition causes problems with mismatched refresh rates, so a browser-based test would only be accurate with a splitter. I've also seen people run into issues with browsers synchronizing to the wrong refresh rate like 60 Hz when the monitor is actually running at 75 Hz. This has caused confusion with the frame skipping test.

A full screen non-browser program could synchronize with each monitor individually, which would eliminate the need for cloning and would allow mismatched refresh rates. The reason I haven't done it yet is because I'm not sure how to implement it. DirectX seems difficult to learn. I just need some way to do fast 2D graphics with perfect vsync on multiple monitors without desktop composition getting in the way.

Re: TestUFO Display Lag Test coming! (SMTT accurate)

Posted: 03 Dec 2016, 14:09
by flood
Chief Blur Buster wrote:
flood wrote:pics?
I'm keeping it top secret until launch of the new TestUFO Lag Test in 2017

Otherwise, people will infer ideas of how I'm pulling it off, and beat me to this motion test.
I want to be #1 for a millisecond-accurate browser-based lag differential test.
well what's the point of posting about it here :P

anyway i'm not sure if it's possible unless both monitor's vblanks (as in the timing of vblank for the signal in the cable) are synchronized. which would require a splitter i believe

Re: TestUFO Display Lag Test coming! (SMTT accurate)

Posted: 04 Dec 2016, 23:20
by Chief Blur Buster
flood wrote:anyway i'm not sure if it's possible unless both monitor's vblanks (as in the timing of vblank for the signal in the cable) are synchronized. which would require a splitter i believe
Splitters are preferred, exactly as for SMTT 2.0

However, there *is* a way to photographically confirm perfect blank sync to an error margin of <0.5ms
(At least with a good SLR, and at least with TN monitors).

I wouldn't mind some peer reviewers, once the methods/instructions are posted, of course. Keep tuned.