Originally Posted by wondras
It's not that I'm reading it incorrectly, it's that I'm looking for something different.
Since a given pixel on a 60Hz display is drawn every 17ms, the timer value should increase by that amount between frames. When you look at just one monitor in any SMTT picture, if a row has a ghost image from the previous frame, the time difference is always 17ms.
What I'm saying is that if the two monitor outputs are exactly
synchronized, i.e., each pixel is created at exactly the same time for both screens, the number being displayed on a specific row
will be the same for both outputs. The delayed values will be a multiple of 17 behind, just as for the previous frame on the single screen. If the difference is not a multiple of 17, then the outputs are not being created in sync, so you know you have a delay between ports. In my case the differences were about 20, indicating a 3-4ms delay.
This is different from measuring the actual input lag, where as you say, you look for the highest number on each screen, regardless of which row it's on.
Since they are usually on different rows, the difference won't be a multiple of 17.
Maybe I really was thinking about this the wrong way, or not all the way through.
Looking back at the test pics I posted, I now see that while the images
are not in sync, the times
really are. In both of the mixed DVI/VGA pics, the pixels that are changing are on different rows, but the times that are changing are the same.VGA-DVI
In this one, both screens are just starting to show 20.812. The positions are different, but the updates are happening at the same time.DVI-VGA
In this one, on the left monitor 08.904 is just becoming clear, and on the right it's 08.905. Given the timer's 1000fps refresh rate, a 1ms difference is within its margin of error, so again the current screen updates are showing exactly the same time.
There's no lag between ports; they're just not synced. SMTT's high-resolution timer reveals this, but also factors it out of the tests (which is the part I was missing.) My TV tests reflect this; with various connection types I was getting different offsets for a given row, but the calculated input lag kept coming out the same.
Sorry if I confused anyone with this.