Quote:
Originally Posted by
forscience 
For modern, progressive scan digital displays, the entire frame is refreshed very quickly, and all at once.
Even all TFTs refresh their display content pixel by pixel, line by line. They do *not* refresh all pixels at once as the wiring does not allow it!
All Pixels (or to be more precise: Subpixels) are wired in a matrix-style and can't be processed all at once.
You can test that yourself with a high-speed photograph of a flickering image or even with SMTT (2.0).
The visible "fade in" and "fade out" of the text ist directly related to the time that has passed since the screen content at that very position started to switch.
If the whole screen would be updated at once the brightness off all numbers (at least of all within a column) would be identically. But they change line by line from top to bottom while SMTT draws them always with the same intensity.
Quote:
The PRAD article helps explain why; the error factors are significant, and there is no standard for measurement.
At least there are many factors that may lead to horrible measurements. That is absolutely correct. Even though SMTT is not perfect it omits most of these problems.
Quote:
Originally Posted by
forscience 
I want to dispel the notion that CRT's have no input lag. This is only partially true. Due to the time it takes to generate an interlaced image, the visual lag from a CRT is *variable* between zero and 33ms, depending on what part of the image is being drawn at any given time.
Interlaced pictures are pretty uncommon in any PC-related scenarios.
You are true that this is different for Video- or TV-related applications. Nevertheless consoles (like the PS3) offer 1080p output signals that are progressive. Interlaced signals are *of course* not suitable for input-lag tests as any full frame will need 33ms to be transmitted to the monitor.
Well, some high-end TVs use all half-frames, store one or maybe even two in a buffer and calculate progressive full-screen images at higher framerates from all the data they can get out of these interlaced images.
But that's not CRT-related: Neither this high-end processing nor the additional delay caused by interlaced signaling. That's an additional problem caused by the signal itself! So please don't blame CRTs for it. I measured input lag on CRTs with progressive signals as I wanted to get a prove for the assumption that they have no input lag.
My measurement showed about 670 ns "input lag" for the CRT - which might also be a combination of "signal travelling time withing the monitor" + "electron flight time to the phosphor" + "phosphor latency until a difference in illumination can be recognized" + "delay caused by the photo sensor".
Nevertheless: 0,00067 ms is that low that it does not matter at all.
Measurements and calculation of this value can be found at page 13 and 14 in this article at PRAD:
http://www.prad.de/en/monitore/specials/inputlag/inputlag-part13.html
One of the included oscilloscope based measurements (V-Sync vs output on screen)

From this value the v-sync to first pixel has been substracted:

As you can see in these screenshots the errors of the measurements are extremely low. 122 picoseconds (!) for the second, 40ns for the first. These measurements are *very* precise.
BUT you have to consider that a single stop watch anywhere on the screen will not be updated as fast as the very first pixel! Forscience is absolutely correct, that something at the lower right hand corner will be updated about 16ms later than the first pixel.
So whenever you take pictures with long aperture time that do not even show the CRT-update process, you won't be able to tell which part of the screen has been updated and which has not.
But that's pretty good covered by SMTT even in the first revision - and better in SMTT 2.0.

It's just important that you use it as described in the manual: Use fast shutter speeds and use only the values that are the newest displayed on the screen.
In this very special case you will get numbers that have just been written on an updated area. Maybe 1ms ago, but there will be neither a 16ms nor a 5ms error. It will be pretty correct - at least for progressive sources like PCs, consoles, 1080p movies, etc.
Quote:
The other method, most useful in auditioning digital displays, is the photocell method, as used in the device being developed by Leo Bodnar. In this method, the source is a burst of white signal, and a counter runs until the white signal is detected by a photocell at the display. In my shop, we are also developing such a device, using Arduino parts, but we will not be bringing it to market. I wish Leo Bodnar the best of luck in marketing his device, as it will be invaluable to those of us who go shopping in the retail stores for new displays. Plug it in, press the button, get an answer. Turn on Game Mode, try again.
Yes this will be quite handy and effective. I really like the idea and device. But it will also be more expensive due to the hardware.
Quote:
SMTT is a good tool, but there is no guarantee of accuracy, between unknown hardware and software interactions, and the inherent inaccuracy of the CRT trace.
The CRT-Trace is covered and does not harm the result of SMTT.
Sorry for the double-posting, but I preferred to answer to this member in great detail with a dedicated posting.