Naveronasis wrote: ↑
09 Jun 2021, 09:10
There is no microstutter so its not doing some kind of on the fly pull down since there are some older displays that will do that.
Since now I know you're familiar with Timings & Resolution;
Frameskipping (pulldown creation) is caused by almost all LCD monitors doing frame buffering of the refresh cycles, and there's 2 separate processing passes: The video signal that writes into the buffer (creating a memory of the refresh cycle in the LCD motherboard's RAM), and the refreshing electronics that reads from the same buffer to the actual pixels (writing to the panel transistors pixels to start the LCD pixel transition).
(Side note: the LCD panel is essentially metaphorically one gigantic write-only memory chip of sorts. One that uses analog levels of molecular rotation (liquid crystal molecules that acts as light valves to block/unblock polarized light) between two glass plates. Same row-column addressing as a typical RAM memory chip, controlling a transistor (active matrix) controlling each sub pixel tile. Except the "memory medium" at the transistor is completely different. Both RAM and LCD panels use lithography as method of manufacture)
In modern low-lag implementations, it's a very tight rolling window buffer between signal and panel (often approx ~6 pixel rows, just enough for scaling processing, ovedrive/color processing, and digital HDMI/DP micropacket dejittering), in a top-to-bottom sweep. Often it's two closely-spaces pixel-row pointers (C++ or FPGA) on the same refresh-cycle buffer in the monitor motherboard's buffer (scaler/TCON), with the panel refresh row chasing behind the signal row. This makes signal synchronized to the panel almost perfectly, for low lag operations.
So that's a very low latency sub-refresh processing for LCD, which is why modern LCDs can latencies within ~2-3ms of a CRT tube (mostly just GtG lag, HDMI/DP codec/modem lag, and micropacket demux from other packets like 2nd display or audio packets, etc). Now the lag difference between a CRT (with the HDMI/DP adaptor and it attendant packetization latencies) and an LCD is now sometimes within 1-2ms difference of the fastest esports LCDs today -- the only way to easily get much lower lag on the CRT is direct analog (from discontinued GPUs with direct VGA outputs to bypass the requisite HDMI/DP codec latencies). Nontheless the esports industry is pushing some crazy optimizations that brings LCD refresh workflow closer to the 100-year-old raster video signal topology...
Sometimes it's a queue of refresh cycle buffers, with the signal buffer writing to a refresh cycle buffer, before the complete refresh cycle buffer is passed along to the panel refreshing code/electronics. But nowadays, pointers can share the same buffer, for low-lag operations, in a "beam-raced" / "beam-chased" operation in a tight rolling window nowadays on esports-optimized panels. These scaler/TCON optimizations filtered down to a lot of generic 60Hz LCDs too (low lag 60Hz LCDs), albiet not all of them, as the full buffer workflow is a lot simpler for color/HDR/etc processing in a lot of TVs (most TVs have at least 1 refresh cycle worth of lag), when gaming low lag operations are not as important. It sometimes is now much higher reprogrammable level -- e.g. an ARM GPU shader that runs on a full frame buffer to process the image nowadays -- rather than optimized FPGA/ASIC stuff. A 240Hz 1080p monitor needs to mathematically reprocess 1.5 billion subpixels per second, so that's literally FPGA or GPU territory if you want to do lots of advanced color processing -- overdrive math, HDR math, etc.
Frameskipping or tearing occurs on some panels because the two pointers (the write pointer to buffer signal to monitor RAM, the read pointer to copy monitor RAM to the monitor panel) are moving at different velocities. As they wrap around at a beat-frequency, you got the attendant stutter (if pointers are on different refresh cycle buffers) and/or tearing (if pointers are on same refresh cycle buffer).
Most "proper" gaming LCDs refresh low latency top-to-bottom like a CRT except in a non-flicker manner (no phosphor fadebehind effect behind the sweep): www.blurbusters.com/scanout
(high speed videos of an LCD refreshing top-to-bottom).
However, the signal velocity and scanout velocity of a LCD can diverge, creating weird latency effects:
Fixed Horizontal Scanrate and Flexible Horizontal Scanrate LCD Panels
TL;DR: The majority of 240 Hz LCDs are fixed horizontal scanrate, which means any refresh rates are output to the panel in 1/240sec top-to-bottom. So it has to buffer any lower Hz, and that adds latency. Fortunately a few cherrypicked 240Hz panels (e.g. ASUS XG258 and the ViewSonic XG2431, probably the world's first multisync-horizontal-scanrate 240Hz IPS LCD) can sync its panel scanout to signal scanout, reducing input lag.
Some fascinating history -- frame skipping (pulldown creation) is still a problem today! Unfortunately a lot of newer displays do too. I've caught a few 240 Hz displays frameskipping, and one manufacturer had to do a stealth recall (RMA). But I discovered some undocumented timings tricks to violates its factory EDID to fix frame skipping via a nonstandard EDID the monitor did not come with. A huge number of AOC AG251FZ (one of the first 240 Hz monitors) had this problem. So users could fix frameskipping in some early 240Hz LCDs with a custom EDID override: Timings Fix for Frame Skipping on 240Hz LCDs
These days, TestUFO has a very particular weekly traffic surge pattern resembling workdays (sinewave from 9am-5pm surge to nighttime quietness during the 5 weekdays) from the Asia region; suggestive of a lot of China/Korea/Taiwan workplaces are using TestUFO (which the Great Firewall is fully completely open to, apparently) -- apparently most manufacturers have now added TestUFO to their display development debugging / testing routines. They learned their lessons on some of the really nasty LCD-specific bugs.