Best way to test display lag?

[Chief Blur Buster]

Wow I had no idea that compact cameras with high speed recording capability were available. I was looking at a Kickstarter the other day for the "first affordable high speed video camera" from last year and it was still $5000, though it does go up to almost 18,000 fps.

First affordable, true high-resolution, high speed camera, yes.

However, lag analysis and strobe backlight analysis can do fine with low-resolution high speed cameras (224x64) which are now readily available at the consumer pricing level. This is digital high speed digital imagery that used to cost a lot of money with supercomputers in the 1980's, even if it's ugly, low-resolution, postage-stamp-size resolution. However, it's perfect for lag analysis and basic strobe backlight analysis for hobbyists, reviewers, and bloggers!

[HeLLoWorld]

I really believe it would be very good too, to be able to test input lag for mouse move.
Although not very likely, there might be a difference compared to fire, be it in the mouse hardware or firmware or in the game engine (and what if game engine does not fire first frame etc)
I know it is far less easy to test, because you's need to kick your mouse so that you can accurately determine the first 1000fps frame where it moves, and the first 1000fps frame where the screen moves. Then analysis of movies is more tedious.

But...After all, mouse move is all that counts...
I mean, compared to fire or keyboard move, mouse move is where lag is paramount.

I thought of putting the mouse on a screen to simulate movement...Then I realized the screen is like 120Hz so thats 8ms. But maybe the real update is quicker so it's feasible. I mean, change the picture under mouse sensor 1 pixel to the left (dunno if it will trick the mouse correctly since they are like 4000dpi/1000Hz, so in real life they should never see such a big move, plus the pixel refresh will be slow to its eyes) and blink the screen around the mouse in red at the same time! Maybe with a smarphone (though prolly lower refresh even) , although quick tests are not successful even dragging the mouse around (not even dragging the picture). However under some circumstances, dragging mouse on pc tft kindof works a little . Maybe the picture must not be too bright.

If someone finds a combination of smartphone screen/mouse sensor/picture that the mouse can move onto, then can drag the picture and the mouse responds, it would be great! Now to see how many frames the phone screen takes to change on a highspeed camera. If it is not too much, this can be done (but I'm not very optimistic).

[HeLLoWorld]

By the way I think it's fair to mention some people were already using the led + video (60Hz it seems) method to test frame lag in 2009 on consoles, there even were modded led controller devices.
http://www.eurogamer.net/articles/digit ... or-article

[sharknice]

hate to crush dreams but numlock and such are actually commanded by your main processor, this was already the case on a 8086! I was shocked too when I learnt that a long time ago!
So there would be some uncertainity about the time of the roundtrip, potentially not negligible.
If the keyboard has full-local circuitry to light up custom leds thats another story of course.

Yeah you're right. It would probably be 2ms with 1000hz polling but it could vary keyboard to keyboard too. I'll have to do some tests to find out with the custom per key LEDs too.

[Chief Blur Buster]

Well, at 144hz the VG248QE has the lowest input lag of all monitors currently available according to multiple websites. Want links to some hard numbers?

I do not trust most sites' hard numbers on input lag, without additional data on what part of the chain is measured, using what. They aren't always specific on what part of input lag chain. Lag relative to scanout? Average lag? Whole button-to-pixels lag? Display-specific lag? CRT measurement method? SMTT measurement method? Leo Bodnar measurement method? They actually end up measuring different parts of the input lag chain, and differential measurements often is out of sync with non-differential measurements. And are you maeasuring lag from signal input to pixel illumation? Lag from signal input to pixel illumation? Lag to first faint visibility of LCD pixel (early in pixel transition cycle?) Lag to final full visibility of LCD pixel (late in pixel transition cycle?) And, even CRTs have input lag, if you're measuring bottom-edge input lag with a Leo Bodnar, because of the scanout delay (for framebuffered architectures).

I can definitively tell you that the scanout of the VG248QE is virtually lagless (~2ms or less), so you're only getting the pixel response lag, so you're only about 1-2ms behind the CRT. Due to the back porch (black scanlines at the beginning of a refresh cycle), you can end up having some lag before the first visible scanline is displayed on a CRT, too, if you're measuring relative to the very start of the dotclock (first pixel transmission, typically a blanking interval pixel). Often less than 1ms, but still a finite lag. I have electronically measured, with a photodiode oscilloscope, the scanout of the VG248QE is only about 3ms for the top edge of the screen, relative to Direct3D Present() of a blank frame buffer, so that includes DVI cable lag (sub 1ms, but not zero). So, this means the differential between a CRT scanout and a VG248QE scanout is only approximately 2ms -- no more than that.

At 100Hz, during VSYNC ON framebuffers, a CRT always has a guaranteed minimum bottom-edge latency of 10 milliseconds, due to the top-to-bottom scanout latency, as you can't refresh the whole screen instantaneously. CRT has essentially, however, zero scanout lag relative to video input (practically effectively zero "pixel in, pixel displayed" lag), when accepting an analog input, and doing real time rasters. But we're using framebuffers on the PC side, so we're now injecting framebuffer latency, which means displays, including CRT, have more input lag for bottom edge of the screen than the top edge of the screen.

Interesting 1980's programming tidbit: Good knowledge about display scanout heavily taken advantage of during the 8-bit machine language programming and raster interrupt days (e.g. Atari TIA, Commodore VIC II, Nintendo, etc), to create special effects such as more than 8 sprites per row, or split screen zones. You really had to understand how the display scanned out, in order to really understand timing-critical raster programming.

[Sparky]

I'm curious about latency consistency. It seems like G-sync should have the potential to be more consistent than vsync off, in that the entire screen is refreshed when the frame finishes, instead of just whatever happens to be below the scanline.

[Sparky]

I really believe it would be very good too, to be able to test input lag for mouse move.
Although not very likely, there might be a difference compared to fire, be it in the mouse hardware or firmware or in the game engine (and what if game engine does not fire first frame etc)
I know it is far less easy to test, because you's need to kick your mouse so that you can accurately determine the first 1000fps frame where it moves, and the first 1000fps frame where the screen moves. Then analysis of movies is more tedious.

But...After all, mouse move is all that counts...
I mean, compared to fire or keyboard move, mouse move is where lag is paramount.

I thought of putting the mouse on a screen to simulate movement...Then I realized the screen is like 120Hz so thats 8ms. But maybe the real update is quicker so it's feasible. I mean, change the picture under mouse sensor 1 pixel to the left (dunno if it will trick the mouse correctly since they are like 4000dpi/1000Hz, so in real life they should never see such a big move, plus the pixel refresh will be slow to its eyes) and blink the screen around the mouse in red at the same time! Maybe with a smarphone (though prolly lower refresh even) , although quick tests are not successful even dragging the mouse around (not even dragging the picture). However under some circumstances, dragging mouse on pc tft kindof works a little . Maybe the picture must not be too bright.

If someone finds a combination of smartphone screen/mouse sensor/picture that the mouse can move onto, then can drag the picture and the mouse responds, it would be great! Now to see how many frames the phone screen takes to change on a highspeed camera. If it is not too much, this can be done (but I'm not very optimistic).

I think it would be most effective to use a microcontroller to simulate a mouse, and illuminate a LED at the same time it gives the computer a movement input.

[Chief Blur Buster]

I'm curious about latency consistency. It seems like G-sync should have the potential to be more consistent than vsync off, in that the entire screen is refreshed when the frame finishes, instead of just whatever happens to be below the scanline.

Agreed, that's correct.
There should be consistency improvements, with G-SYNC, yes. It didn't show up clearly in my tests, but there was so much latency variability by other factors (e.g. CPU variability, GPU variability, game programming variability, and other variability factors) that latency-consistency-improving factors of G-SYNC was likely simply lost below the noise floor of other latency variability factors.

However, I will eventually test more games, as well as get other people (with modded mice) to do high speed camera tests for future Blur Busters articles. If you are someone who is willing to do my invention of lag testing (mod a computer mouse, and use a cheap $150 high speed camera such as Casio EX-ZR200) we'd like to publish your lag tests here at Blur Busters. Send me a PM.

[Chief Blur Buster]

I think it would be most effective to use a microcontroller to simulate a mouse, and illuminate a LED at the same time it gives the computer a movement input.

Could work, but admittedly far harder than hardwiring a LED physically to the mouse button.
There are already tools that measures mouse movement consistency (from poll to poll).

Also, measuring mouse movement by high speed camera won't be as reliable as measuring button by high speed camera, because an accidental micro movement of the mouse might not register in the drivers, while early almost-stationary movement of the mouse might cause the LED to light early while there is no movement in the high speed video. Mouse movements is currently very hard to benchmark input lag on, because there's so many opportunities for false alarms (LED not lit versus LED lit prematurely) and undetected moments in high speed video. The button becomes a far easier benchmark, because a click is guaranteed sent when the LED is lit up. It's super-simple ON/OFF logic, the mouse button completes the electrical circuit for the LED, and the mouse button registers a fast, violent, immediate on-screen action (gunshot that's easily captured into high speed video). Sometimes there's movement (crosshairs glow, crosshairs expand, upwards screen shift, etc) before the muzzle flash, but something big always suddenly happens when clicking the mouse button in an FPS, so it's very easy to capture in high speed camera. Very deterministic start (LED illuimination) and very deterministic end (screen reaction). The error margin for mouse clicks become small, with easy potential for only a +/-1ms error margin in high speed video input lag testing. You can't get that reliably deterministic with mouse movement input lag testing.

I certainly would love to hear ideas, if it could be as simple and deterministic as a buttons-to-pixels high speed camera test. The mouse button modification takes only 30 minutes, and the high speed video camera is cheap ($150), something totally doable by an average blogger/reviewer site. The likes of AnandTech and TomsHardware can easily take my idea (please give me credit) for the high speed video input lag testing.

[Chief Blur Buster]

By the way I think it's fair to mention some people were already using the led + video (60Hz it seems) method to test frame lag in 2009 on consoles, there even were modded led controller devices.
http://www.eurogamer.net/articles/digit ... or-article

Good catch. I never knew about it, as I invented the technique from scratch, but for computer mice. The prior art does not appear to use high speed video. My method achieves millisecond-league accuracy via high speed video. But definitely, a prior art that is very interesting and worth mentioning. That said, I'd still appreciate credit if any website would love to use the method (go right ahead, just mention that Blur Busters came up with actual successful usage of mouse+highspeed video combo).