RLCScontender wrote: ↑26 Jun 2020, 22:06
part 1.5 INPUT LAG Acer Predator xb273x review cont..., the
#1 overall LOWEST input lag out of any monitor that isn't a CRT display
. Sorry for the delay gentlemen but chief brought up a very important point. I really had to figure out how my friend james got those numbers of .03ms input lag because i too was skeptical. I belileve response times and input lag is the #1 most important variable when it comes to buying these expensive monitors and because this topic gets a lot of traffic, the UTMOST ACCURACY of these tests HAS to be backed up by evidence and explanations.
There are many legitimate ways to measure input lag, but I disagree about quoting only one lag number. Your pre-GtG lag number is what I consider a "synthetic lag benchmark" that can decouple from actual human reaction relevance, especially with multiple interactions with different sync technologies. However, what you're doing is not too different from many sites so I have to be fair in dismissing synthetic lag numbers that somewhat decouples from actual human-detectable photons hitting human eye balls.
So I'll add a disclaimer tag: Blur Busters does not sanction these lag numbers as being really relevant.
RLCScontender wrote: ↑26 Jun 2020, 22:06
Perceived input lag (display lag)
1.27ms(half of my pixel g2g response time measurements) also known as response time element
Mathematically half a GtG100% or even half a GtG(10%->90%) is a reasonable approximation, as long as this is honestly disclosed. However, if one wants to be even more accurate, measure the actual point where the GtG50% occurs -- usually it's earlier of the exact half of a GtG(0%-to-100%) or a GtG(10%-to-90%) as VESA standard.
Now, mind you, GtG(0%-to-100%) is hard to measure because of noisefloors of oscilloscopes, and I've seen different oscilloscopes change GtG(0%-100%) numbers by an order of magnitude, with Brand X oscilloscope having more "noise" and less precision than Brand Y oscilloscope, making it hard to figure out where GtG0% is and where GtG100% is, because of noise in the oscilloscope graph.
However, halving a full VESA GtG measurement is often mathematically simpler.
RLCScontender wrote: ↑26 Jun 2020, 22:06
0.01ms ACTUAL INPUT LAG (how snappy you feel when pressing a button relative to the game u are playing)(the moment you press a button, it should be instantaneous.
0.01ms signal processing lag.
That's a phrase fail, I'd delete "
ACTUAL INPUT LAG" as that is an opinion inserted as a fact, because of the complexity of displays -- not all pixels refresh at the same time (aka scanout lag -- see high speed videos of
www.blurbusters.com/scanout ...) since single-number lag numbers are often usually synthetic.
RLCScontender wrote: ↑26 Jun 2020, 22:06
why 1.27? Because for me,
it doesn't take the whole pixel transition to perceive the g2g color changes(although i only speak for myself, i have 20/20 vision) of the 2.54 pixel response time that i measured on this monitor. . 1.27ms (or half of the g2g respones times) is a safe bet.
That's why I recommend some lag testers use GtG10% (the beginning of the VESA GtG stopwatch), as the input lag measurement. Because GtG 10% begins to become reasonably human visible, that's basically a dark grey in a "full-black to full-white", or a ultralight grey in a "full-white to full-black" transition.
However, this is simply a Blur Busters cutoff opinion. That said, I consider all single-number lag measurements using near GtG0% to be simply synthetic lag numbers like CrystalDiskMark is for disks. They're useful, but they're not real-world lag numbers. That said, we're just nitpicking over milliseconds for the large part.
However, 0.0x milliseconds means other things are bigger error margins that can make a monitor A-worse-than-B and B-worse-than-A based on other latency-affecting variables outside the chain of lag that you measured!
RLCScontender wrote: ↑26 Jun 2020, 22:06
Then again, i DO NOT CONSIDER THIS INPUT LAG, I CONSIDER the non-existent processing delay input lag because that is when you press the button and the thiing u are controlling on the monitor will instantly move.
You used the phrase input lag a few times in contexts that are somewhat questionable, then -- please make sure you're terminologically correct in scientific contexts. Math is a universal language, and this also applies to lag mathematics.
RLCScontender wrote: ↑26 Jun 2020, 22:06
Hopefully i got that cleared up for everyone.
Better, but not quite.
RLCScontender wrote: ↑26 Jun 2020, 22:06
1.28ms input lag of total display lag+processing lag
or
.01ms input lag(the amount of time AFter pressing a button, the soldier/character/car/batman/hipster/dog/mario/sonic/etc you are controlling will move(how
snappy u feel)
Unless you misphrased accidentally or used the wrong phrase accidentally, that's mathematically impossible because "button to photons" latency is much bigger than "display lag + processing lag"
This is because "button to photons" (bigger number) is a superset that includes "display lag + processing lag" (smaller number). You can't do the latency equivalent of "2 + 2 = 1". Adding two positive numbers never creates a smaller number than the original number!
I have to uphold Blur Busters to the proper academic standards of latency disclosure, so please re-evaluate your latency measurements.
