[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.
uberniner
Posts: 10
Joined: 01 Aug 2014, 02:42

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

Post by uberniner » 01 Aug 2014, 03:00

Hi there!

Recently I received the ASUS ROG Swift for review at PCTuning.cz. I decided to measure also the inputlag of this screen.

Since the flash stopwatch/timers are quite a BS I went for my implementation.

Done in Qt and OpenGL, it renders around 1000 fps with timer info in milliseconds in columns + fps in the middle of the screen.

It works rather well, You can detect even quite small differences in inputlag, also you can see how long it takes to fully switch the pixels etc.

The weird thing is, that in clone mode at the same frequency, both screens are perfectly in sync regarding the refresh signal.

For CRTs its quite OK to see it, makes sense, since the GFX drives the signals.
DSC_7572.jpg
DSC_7572.jpg (48.42 KiB) Viewed 7006 times
For CRT + LCD it begins to be a bit strange. I always thought that the LCD uses its own refresh signal, but here its synchronized. Even if its connected trough DP or DVI.
DSC_7465.jpg
DSC_7465.jpg (43.71 KiB) Viewed 7006 times
Finally two LCDs, and same perfect synchro.
DSC_7502.jpg
DSC_7502.jpg (56.71 KiB) Viewed 7006 times
Why do you think this happens? Is it the GPU that gives the refresh signal to the LCDs/CRTs?

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

Re: Precise inputlag measurements revealed disturbing facts

Post by flood » 01 Aug 2014, 05:01

nice work

what graphics card are you using?

that synchronization between the crt and lcd is incredbile


see this article
http://www.prad.de/en/monitore/specials ... art17.html
uberniner wrote: For CRT + LCD it begins to be a bit strange. I always thought that the LCD uses its own refresh signal, but here its synchronized. Even if its connected trough DP or DVI.
DSC_7465.jpg
looks like there's 1-2ms of input lag on the lcd (i.e. lcd vs crt + your gfx card's dac)

crt is already scanning well under 969 whereas the lcd is switching the lines near the top of 952 and bottom of 969


by the way, you should check your camera for rolling shutter. I'm guessing it scans from top to bottom or bottom to top, in which case it's crucial to have the monitors aligned to the same height.

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

Re: Precise inputlag measurements revealed disturbing facts

Post by uberniner » 01 Aug 2014, 06:49

flood wrote:nice work

what graphics card are you using?
i run on gtx680 lightning

my camera is nikon dslr D7000 with shutter speed set over 1/1000

about the lcd vs crt synchro - I believe its on the exactly same spot, the fact that 952 fades is just pixel persistence, as well as that the 969 is already scanned out completely.

My question is - why on earth are those 2 that well synchronized? It looks like the GFX sends this kind of a refresh timing to the screen a effectively forces it to both screens. It dont mean that it can do it adaptively like G-Sync, but perhaps by using LCDs internal PLL it eventually synchronizes the refreshes.

I could provide more images, but its always the same story.

Q83Ia7ta
Posts: 761
Joined: 18 Dec 2013, 09:29

Re: Precise inputlag measurements revealed disturbing facts

Post by Q83Ia7ta » 01 Aug 2014, 08:19

uberniner wrote:My question is - why on earth are those 2 that well synchronized?
May be 144Hz is too big value (6.94 ms) to be non synchronous. I did similar tests and had same big amount of identical "millisecond times" but when I disabled "Instant Mode" on BenQ there was difference in results (photos). That test was done on two 144Hz monitors in clone mode.

Did you try to use extended mode instead clone and make your application in window mode and put window in between two screens like this:
Image

Ofc needs to be sure v-sync is off. I understand that fullscreen is more native/accurate (for opengl/videocard).
Great work. When approximately will you publish your input lag test results of ASUS ROG Swift?

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, 08:37

"Proper" VSYNC OFF is not really possible in windowed mode on Windows 8, due to enforced window compositing. You must create you lag tester app in full screen mode if you use the 1000fps VSYNC OFF techniques.

I have invented a new technique of measuring input lag differentials with great accuracy that works with VSYNC ON for two-monitor comparisons. Fully as accurate as the 1000fps testers, while only needing 60fps@60Hz (or framerate matching refreshrate). I will be announcing the new input lag testing technique later this year. But I will not be using this technique for the ROG, but using the highspeed video method that I did at http://www.blurbusters.com/gsync/preview2
It is also important to understand how tearing interacts with impulse/non impulse displays such as CRT vs LCD, while accounting for phosphor fade versus GTG transitions. You need to design input lag test patterns accordingly to be compatible with both display techniques.

To familiarize with LCD refreshing behaviour, they scan like CRTs except they do not fade after scan. Pixels fade from one color to the next during transitions only. See high speed videos of LCD refreshing to better understand how they refresh! they are simply high speed videos of http://www.testufo.com/flicker

Also, consider other variables interfering with input lag measurements:
http://forums.blurbusters.com/viewtopic.php?f=10&t=641

Also, when testing ghosting, do not use the outdated PixPerAn which works unreliable under Windows 8. but use TestUFO. For ghosting tests, I suggest either http://www.testufo.com/ghosting or the TestUFO Alien Invasion Test (Heigt set to full screen) since ghosting can be different at top edge versus bottom edge, especially with strobe modes such as ULMB.

Keep tuned on the timing of my lag tests.

Please also study http://forums.blurbusters.com/viewtopic.php?f=5&t=1177 ... Including the importance of a 1000Hz mouse with this monitor.

Fellow monitor reviewers are welcome at Blur Busters Forums. I help all friendly reviewers. For the "Better Than 60Hz" arena, many are using a lot of my ideas and inventions, as I come up with them. Good luck on your ROG PG278Q review!
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, 11:27

Hello guys, and thanks for the response. By the way, great job, what you are doing here, I really appreciate it.

At first - what do you mean by proper vsync off? I mean, can there be a state between on and off?

Anyways I ran the tests at fullscreen and could see actually many tears + times differentiating by 1ms meaning there is more fps rendered then refresh rate. That is by my book an indication of Vsync off. Am i wrong?

So considering the test executed at fullscreen and vsync off, is there any reason why the signals keep synchronized?

PS I test on W7 not W8

PPS I improved my tester to run more with more numbers (and lines) and at 5k fps, just to be sure nothing is lost. I will provide screens a bit later.

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

Re: Precise inputlag measurements revealed disturbing facts

Post by flood » 01 Aug 2014, 13:52

vsync off windowed mode is possible on w8 albeit with a buggy/blank start screen
google "windows 8 disable compositing"


even if the shutter speed is 1ms, there probably is still rolling shutter. e.g. the top of your image takes data from t=2ms to 3ms, the middle part takes data from 4-5ms, the bottom part takes data gfrom 6-7ms, etc...

i think on dslrs, the total time difference between top and bottom is the xsync time

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

Re: Precise inputlag measurements revealed disturbing facts

Post by uberniner » 01 Aug 2014, 15:00

ok, i will level the screens to the same height and shoot with even higher speeds, perhaps 1/4k could do. What do you think?

Btw does anyone know how to setup gsync screen and at the same time duplicate to nongsync screen and run a fullscreen app (game) in gsync mode on one screen and just normal non sync on the other? I mean like a gsync to nongsync realtime comparison.

PS Since I use Qnix I can run Qnix and PG278 at cloned mode at different refresh rates. I tried the same with a CRT and it worked one, but next time I tried I coulnd get it to work (the 144hz from asus was automatically set on the crt, which couldnt handle that)

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, 15:18

uberniner wrote:Hello guys, and thanks for the response. By the way, great job, what you are doing here, I really appreciate it.

At first - what do you mean by proper vsync off? I mean, can there be a state between on and off?
There are interactions. For example, windows compositing behaves as an extra buffer. You never see tearing in most windowed games when you turn VSYNC OFF because it behaves as de-facto triple buffer.

VSYNC OFF + window compositing == equals VSYNC ON triple buffered

This will interfere with an incorrectly-functioning lag tester. Fortunately, this does not apply if:
uberniner wrote:Anyways I ran the tests at fullscreen and could see actually many tears + times differentiating by 1ms meaning there is more fps rendered then refresh rate. That is by my book an indication of Vsync off.
This is correct. At 1000fps at 100Hz, you should see about ten tearlines per frame (except for tearlines hidden at the top/bottom edges of screen, aka blanking interval between refreshes). Framerate divided by hertz gives you the count of tearlines per refresh cycle.

Also, tearlines are always in identical positions on both LCD and CRT. The scanout is identical top-to-bottom, except for the lack of fade-to-black on a LCD.
uberniner wrote:So considering the test executed at fullscreen and vsync off, is there any reason why the signals keep synchronized?
This is normal. Modern ASUS/BENQ TN monitors are capable of realtime refresh. The LCD pixels refresh "off the wire". BENQ calls this "Instant Mode". TFTCentral confirms near-zero input lag difference with a CRT.

Surprised? Welcome to the world of near-zero-lag LCDs, if you have never witnessed one. Most TN gaming monitors do this technique nowadays, thanks to the input lag race. A few IPS gaming monitors like EIZO FS2333 do the realtime scanout technique too.

The 1ms pixel response makes the realtime scanout much easier to see, in photos and high speed video.
uberniner wrote:PPS I improved my tester to run more with more numbers (and lines) and at 5k fps, just to be sure nothing is lost. I will provide screens a bit later.
5000fps will definitely improve your input lag tester, to approximately 0.2ms framerate-related granularity error. Your GtG will be the biggest error margin, as will your camera sensor rolling scan. Use an SLR camera with a fast global readout, to get ~1ms error or less. Smartphone sensors often inject over 5ms error in photos, when each corner of the image have four different latencies!!

Your program will not easily measure input lag of the ROG, since it's input lag falls well below the error margin of SMTT-style tests. TFTCentral numbers reflects the uncertainty, by adding an estimate caused by GtG transitions. Tiny numbers will help, as is designing the test to make midpoint measurements easier. If cleverly designed you might be able to notice the ~1ms-2ms lag caused by GtG, but one need to understand how LCD refreshes. A pixel fades from one color to the next, this is the GTG transition. The midpoint of the GTG is where lag should be declared, although there are arguments about where in the GTG to declare the lag at (first faint visibility? Or full pixel visibility?). Thusly, the real world GtG in milliseconds is another error margin. Keep this in mind. The typical signal lag in modern 120Hz TN monitors is now so tiny, that even the GtG dominates the lag measurement, as seem in the TFTCentral chart.
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!

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

Re: Precise inputlag measurements revealed disturbing facts

Post by flood » 01 Aug 2014, 15:25

Chief Blur Buster wrote: Also, tearlines are always in identical positions on both LCD and CRT. The scanout is identical top-to-bottom, except for the lack of fade-to-black on a LCD.
for uberniner's system yea, but for my system (gtx 750ti, win7 clone mode) the tearlines are always different.
5000fps will definitely improve your input lag tester, to approximately 0.2ms framerate-related granularity error. Your GtG will be the biggest error margin, as will your camera sensor rolling scan. Use an SLR camera with a fast global readout, to get ~1ms error or less. Smartphone sensors often inject over 5ms error in photos, when each corner of the image have four different latencies!!
you'd need a leaf shutter to get timing consistent along the entire frame.

for smartphones, it's not like the scanout is diagonal... so i'm pretty sure the timing will always be consistent in a column or a row, depending on orientation.

my iphone 5 has far more than 5ms differences between the top and bottom edge when taking pictures.

@uberniner: suggestion: draw a line to the left of the number for every frame, so that you know where in the picture the lcd panel is updating. make the line move a bit to the right every frame. then your pictures will show for instance
...|....
....|...
.....|..
......|.
.|......
..|.....
here it's obvious that the panel has just updated the 4th row.
Last edited by flood on 01 Aug 2014, 15:36, edited 4 times in total.

Post Reply