SS4 wrote: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.