[I'm a reviewer] Quirks measuring input lag of ROG by camera

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Precise inputlag measurements revealed disturbing facts

Post by Chief Blur Buster » 01 Aug 2014, 16:15

flood wrote:and for me, even if I use the same refresh rates, the displays are still not synchronized.
It is also important to have a distinction:
"The two outputs are not synchronized with each other" (signal output lag: both frames not being output simultaneously)
Versus
"The monitor refreshes are not synchronized in the camera photo" (monitor lag)

That is what I mean. If tearlines are different positions for the SAME frame number, you got unsynchronized outputs, as if two asynchronous page flips are occuring at different times inside the GPU (e.g. Two separate indepdent framebuffer chains running in parallel in the drivers). It is possible to run separate front buffers in the driver software, one for each cloned output, to permit different refresh rates for different cloned output. This causes input lag differences between the cloned outputs. Different tearline positions for the SAME frame number, is a telltale sign of this occuring. To avoid this malarkey hooey, you need to use a splitter, or do careful tests that the cloning is in sync (at the signal output level, nothing to do with the monitor), before trusting cloned output.

It is important to interpret the results correctly.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

uberniner
Posts: 10
Joined: 01 Aug 2014, 02:42

Re: Precise inputlag measurements revealed disturbing facts

Post by uberniner » 01 Aug 2014, 16:20

Chief Blur Buster wrote:
uberniner wrote:This is what I was asking about in my main question. If you could enlighten me a bit more in this area I would be grateful. What makes the LCD and CRT scan-out identically? It looks like the GPU is driving all clocks etc. What I originaly though was happening: LCD has internal Clock generator that drives the refresh rate and if GPU wants to get in sync, the gpu has to adjust according to the clock of the screen.
This is not how things work. The tearing occurs at the video output, by the GPU essentially splicing the next frame immediately into the output. The tearing does not happen in the monitor. The monitor input lag can be completely indepdent of the tearing. Imagine a tape delay on the cable, you will still have tearing in the same positions. Monitor input lag is simply like a tape delay. GtG sort of behaves like that. It has nothing to do with tearing or GtG.
I think we are out of sync now :D I am not talking about tearing (I am not even mentioning it :p ), but I try to find out about the refresh rate scanning (if thats how it is called) and what i mean is the synchronization of it (e.g. on crt synchronization of electron beam). At this point my understanding is that the GFX dictates the clocks of the refresh and thus they are synchronized (if they are the same ofc.). I understand how tearing is beaing created (e.g. page flipping) but I thought that the LCDs generate refresh rates for themselves. And this is what I want to get to the core of. Thanks for the patience ;)
Chief Blur Buster wrote: Good step, but replace your camera. I immediately recognize a camera scanout artifact that adds several milliseconds error.
What is this scannout artifact? So I can perhaps adjust my camera or try another one.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Precise inputlag measurements revealed disturbing facts

Post by Chief Blur Buster » 01 Aug 2014, 16:28

uberniner wrote:I think we are out of sync now :D I am not talking about tearing (I am not even mentioning it :p ), but I try to find out about the refresh rate scanning (if thats how it is called) and what i mean is the synchronization of it (e.g. on crt synchronization of electron beam). At this point my understanding is that the GFX dictates the clocks of the refresh and thus they are synchronized (if they are the same ofc.). I understand how tearing is beaing created (e.g. page flipping) but I thought that the LCDs generate refresh rates for themselves. And this is what I want to get to the core of. Thanks for the patience ;)
It is not as simple as "an LCD generates refresh rates for themselves". It is an old outdated quote. Some do, but the gaming monitors are auto syncing on the signal. They refresh synchronously. My BENQ Z-Series XL2720Z is even more multi sync, capable of auto syncing the LCD refresh exactly to input, even at a 114.735Hz or 89.247Hz in a Custom Resolution Utility. The modern TN gaming LCDs scan out at exactly the same vertical speed as a CRT connected to the same signal. The only difference is the lack of fade-to-black trailing the scan.
uberniner wrote:
Chief Blur Buster wrote: Good step, but replace your camera. I immediately recognize a camera scanout artifact that adds several milliseconds error.
What is this scannout artifact? So I can perhaps adjust my camera or try another one.
Before I answer more fully, what exposure length did you use for these specific photos, and which model camera did you use? Many cameras have a 1/250sec scanout as flood says, which adds approx 50% error to a 120Hz refresh. Try testing portrait versus landscape as some cameras scan sideways, and seeing how the resulting lag photos differs. Good verification exercise of camera scanout interference with lag tests such as these.

It is also helpful to run a camera scan-artifact verification test animation at the edges of an input lag test pattern (like a rapidly color-changing boundaries at top, bottom, left, right edge) and try both portrait and landscape camera orientations. You will see left-to-right discounts during sideways scan. But that will also skew a CRT scan (looking diagonal-ish in a camera exposure), so a CRT is another method of checking the scan direction of your camera sensor.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

uberniner
Posts: 10
Joined: 01 Aug 2014, 02:42

Re: Precise inputlag measurements revealed disturbing facts

Post by uberniner » 01 Aug 2014, 16:34

Chief Blur Buster wrote:Before I answer more fully, what exposure length did you use for these specific photos, and which model camera did you use? Many cameras have a 1/250sec scanout as flood says, which adds approx 50% error to a 120Hz refresh. Try testing portrait versus landscape as some cameras scan sideways, and seeing how the resulting lag photos differs. Good verification exercise of camera scanout interference with lag tests such as these.

It is also helpful to run a camera scan-artifact verification test animation at the edges of an input lag test pattern, and try both portrait and landscape camera orientations.
1/4000s and its nikon d7000

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: Precise inputlag measurements revealed disturbing facts

Post by flood » 01 Aug 2014, 18:16

this is the thing we're concerned about. 1/4000, 1/2000, 1/1000 don't matter much when it takes 1/250 for the entire shutter to move across the sensor.
Image

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: [I'm a reviewer] Quirks measuring input lag of ROG by ca

Post by Chief Blur Buster » 02 Aug 2014, 10:41

Good diagram of a rolling shutter - did you create that yourself?

Yes, even a 1/4000sec shutter can inject a 1/250sec error (4ms) due to the rolling shutter.

P.S. I renamed the topic title as it has become a comprehensive analysis of the complex considerations attempting to measure input lag via camera method.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

uberniner
Posts: 10
Joined: 01 Aug 2014, 02:42

Re: [I'm a reviewer] Quirks measuring input lag of ROG by ca

Post by uberniner » 02 Aug 2014, 12:43

Thanks for the info about rolling shutter, I knew about it but havent realized that it will affect the test.

So I went to search some solution. A CCD camera instead of the CMOS seemed easy. Quickly I found out, that CCD is quite rare, but guess what - I bought a compact camera for my mother and its a CCD. I guess Im really lucky.

I did some nice photos that demonstrate the rolling shutter, I will upload them soon.


Still I fight an issue. Is there any way to run two screens at cloned mode each with different refresh rates? E.g. ROG with 144 and CRT with 85.

uberniner
Posts: 10
Joined: 01 Aug 2014, 02:42

Re: [I'm a reviewer] Quirks measuring input lag of ROG by ca

Post by uberniner » 02 Aug 2014, 12:53

Chief Blur Buster wrote: Yes, even a 1/4000sec shutter can inject a 1/250sec error (4ms) due to the rolling shutter.
horizontal is "fine"
DSC_7663.JPG
DSC_7663.JPG (184.76 KiB) Viewed 6909 times
but vertical shows the delay of rolling shutter
DSC_7664.JPG
DSC_7664.JPG (163.13 KiB) Viewed 6909 times

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: [I'm a reviewer] Quirks measuring input lag of ROG by ca

Post by flood » 02 Aug 2014, 14:14

Chief Blur Buster wrote:Good diagram of a rolling shutter - did you create that yourself?
it's from wikipedia :lol:


I wouldn't call it "4ms of error" because you can usually estimate precisely how much error there is

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: [I'm a reviewer] Quirks measuring input lag of ROG by ca

Post by flood » 02 Aug 2014, 14:20

uberniner wrote: but vertical shows the delay of rolling shutter
DSC_7664.JPG
what Hz was the monitor running at?

that's a lot less rolling shutter than what 4ms looks like.
well you probably cropped the image so that's why.

Post Reply