Would a modern CRT make any sense?

pendragon1 · May 28, 2026

something like this?
https://blurbusters.com/crt-simulation-in-a-gpu-shader-looks-better-than-bfi/

elvn · May 28, 2026

sethk said:
With a 960-1000hz oled you could run an electron beam / crt phosphor simulation that was a very good CRT replica with similar MpRT (motion clarity) and look to the CRT of your choice, minimal lag and still brighter than most crts. It would also keep many other advantages compared to a traditional CRT.

HDR is a "brighter range of colors" , or "brighter color volume ceiling". HDR has a much higher and wider color volume ceiling than SDR (Standard Dynamic Range). SDR is around 100 to 150 nit technically, and up to maybe 300 nit functionally for modern screens in bright room usage.

What you'd get out of an aged fw900 crt now, without compromising parameters, even after refreshing (according to google) :

"
FW900’s maximum brightness remains relatively uniform across the screen: [1, 2]

10% to 50% screen: ~115 to 125 nits
100% full screen: ~95 to 110 nits [1, 2, 3]

Usage Context in 2026:
Because these monitors are now decades old, actual performance depends entirely on the cathode tube's wear. Degraded tubes or units needing G2 voltage/WinDAS calibration often max out lower (60-80 nits). To preserve the remaining lifespan of the components, most users calibrate to about 80–100 nits and use the monitor in dim ambient lighting. [1, 2, 3, 4, 5]
"

HDR color

Modern screens have an enormously larger palette of colors that provides much more details in colored objects, details that aren't even there otherwise, and provides much more contrast with the color-brightness range. I think people diminish the impact of HDR when they just say "it's brighter" as if it was SDR's colors remaining relative to each other and just being ramped up a little higher. I don't know if people imply that intentionally or not, or are in some cases just not being very knowledgeable about how HDR works, or maybe just assuming people know what they mean, - but the end result when people just say "brighter" is that it often comes off as a major downplaying to me. CRT doesn't even have HDR brightness and contrast, and it is at 16.7 million colors instead of 1.07 billion colors of a modern 10-bit HDR gaming display. A 12-bit capable display would be able to show 68.7 billion colors.

. . . .

sethk said:
With a 960-1000hz oled you could run an electron beam / crt phosphor simulation that was a very good CRT replica with similar MpRT (motion clarity)

I think the fw900 crt gets max around 2560x1600 at 75hz, so 75 fpsHz of motion definition/pathing articulation/smoothness at a sub 4k resolution on a small screen size. Even if it gets really good motion clarity/blur reduction, that's another big tradeoff. Depending on the age of the phosphors, it might get 1ms to 3ms persistence.

Every time you double the Hz (on an oled), you cut the sample-and-hold "persistence" blur by half.

According to Blur Busters, eliminating motion blur on a non-strobed LCD or OLED (sample-and-hold) display requires reaching 1000 Hz natively. [1, 2, 3]
The transition thresholds define this path to perfect CRT-level clarity: [1]

60 Hz: Standard non-strobed sample-and-hold display; maximum motion blur.

120 Hz to 240 Hz: Reduces motion blur by roughly 50% to 75% compared to 60 Hz.

480 Hz: Considered the minimum threshold to simulate near-perfect, blur-free motion without flickering.

1000 Hz: The mathematical equivalent to human-perceived CRT motion clarity without any strobing or Black Frame Insertion (BFI)

If you start off with a 100fps native before you amplify the frame rate x5 or 10x , your base is ~ 10ms frames in regard to when you see new (native) motion states and have a window to react/see your reaction (locally). It would also be 1/2 crt level blur at ~ 2ms when amplified x5 to 500 fpsHz on a 500hz capable OLED, which is still quite good, and when amplified to 1000fpsHz on a 1000Hz capable OLED it would be 1ms persistence/blur which is comparable to a crt (especially aged phosphors ones that remain) , so you wouldn't need to emulate anything as far as reducing blur to crt levels once you hit 1000fpsHz, though you might want to emulate the crt "look" for low bit arcade games or something, but you could get that with filters more or less instead I think, (and that is kind of niche, anyway).

image from: Blur Busters Law: The Amazing Journey To Future 1000Hz Displays

. . . . . . .

Amplifying a strong base native frame rate like 100fps solid would:

keep frame lag reasonable for most not-extremely-competitive games at ~ 10ms , which is where 120Hz OLED gaming TVs input lag were at for quite some time, and if not competing in a LAN gaming competition, online gaming server dynamics reduces how meaningful extreme local fpsHz is vs the server relationship physics and tick rates, since you have a "displacer beast" type effect on locations/time, plus your local game is simulating action state frames while waiting on the server's low tick rate updates of interpolated results, among other things. Nvidia has some lag reducing tech tricks, too, as someone mentioned. The version I saw was mainly for sideways movement "doom" like shooters panning left and right, where it was using projection type guesswork to reduce input lag (which appeared to be similar to some of the tech VR headsets use).
that 100fps native x5 or x10 would be keeping a solid amplified frame rate of 500 or 1000, so no VRR would be necessary. The frame durations would all be the same (2ms or 1ms), and there would also be no OLED VRR flicker.
100fps solid would provide a smaller gap of time that AI/machine learning would have to guess between in order to "tween" manufactured frames. The higher the native frame rate and the higher the native resolution of the screen and the resolution you are amplifying from (1440p upscaled via DLSS quality on a 4k screen, or nearly 4k (4096x2034) upscaled via DLSS quality on a 6k screen), the higher the % accuracy of the manufactured frames will be. In other words, the less that has changed between frames due to having a higher frequency and finer detail, the better it will end up. "you can't get blood from a stone", at least not without worse results (bad input lag, more artifacting, + more obvious artifacts with lower resolutions). I recently saw someone saying something like : "dlss+MultiFrameGen makes good frame rate gaming better, it doesn't make bad frame rate gaming good".

.

sethk · May 29, 2026

pendragon1 said:
something like this?
https://blurbusters.com/crt-simulation-in-a-gpu-shader-looks-better-than-bfi/

Yes exactly - mprt from electron beam / phosphor fade simulation is very cool, and I have tried it on my 240hz oled. With 480hz you can see the improvements and at 960 it should be perfect.
The beam tracing / per pixel impulse based method of crt illumination is what gives CRTs such sharp motion clarity at lower refresh rates (no sample and hold effect) and recreating this on an oled using per pixel phosphor fade has the same exact “feel” as CRTs. It’s not about motion interpolation and making up data, it’s using an accurate simulation to solve the psycho-visual effects of seeing the same lit pixels fixed in space over an extended period of time. Two different approaches, but I am definitely looking forward to this method as an alternative to frame interpolation alone at high frame rates. It’s a very good use of that high frame rate possible on upcoming Oleds.

Nobu · May 29, 2026

I know other technical problems would be introduced, but I wonder if dual gun CRTs would have found success in TVs/monitors if the tech had continued to advance.

Theoretically, it could have allowed almost double the refresh rate, at the cost of signal (and beam) complexity.

https://vintagetek.org/dual-beam-crt-guns/

elvn · May 29, 2026

.

Nobu said:
I know other technical problems would be introduced, but I wonder if dual gun CRTs would have found success in TVs/monitors if the tech had continued to advance.

Theoretically, it could have allowed almost double the refresh rate, at the cost of signal (and beam) complexity.

https://vintagetek.org/dual-beam-crt-guns/

That is interesting, but it points out that - yes the refresh rate is poor on crts. Blur reduction from higher hz is part of the gain for LCD and OLED, but the other gain is motion definition/pathing articulation/smoothness (and even animation cycle frames) from higher fpsHz. That aspect overall probably has appreciable gains to at least 500fpsHz if not higher.

warning: photo "gallery" inside this quote

.

1000 fpsHZ using brute force multiFrameGen is the goal. 1000 fpsHz would be crt clarity then, without using crt emulation, bfi, partial scan, etc.. Before we can achieve that (1000 Hz OLEDs), having ~ 500 fpsHZ solid at 4k, 4k+ would be only 2ms / 2pixel persistence which would very close, even if not pristine yet.

1000 fpsHz once available will be game over, at least for crt persistence / image clarity comparisons, and that without any (especially HDR) image brightness reduction, flicker (conciously visible or not can cause fatigue over time), etc.

"According to Blur Busters, eliminating motion blur on a non-strobed LCD or OLED (sample-and-hold) display requires reaching 1000 Hz natively. [1, 2, 3]
The transition thresholds define this path to perfect CRT-level clarity: [1]

60 Hz: Standard non-strobed sample-and-hold display; maximum motion blur.
120 Hz to 240 Hz: Reduces motion blur by roughly 50% to 75% compared to 60 Hz.
480 Hz: Considered the minimum threshold to simulate near-perfect, blur-free motion without flickering.
1000 Hz: The mathematical equivalent to human-perceived CRT motion clarity without any strobing or Black Frame Insertion (BFI)

"

-------------------------------------

If you have post DLSS quality boosting your native frame rate to 133fps (7.5ms), after applying MultiFrameGen x4 you'd end up with 505 fpsHz (average, not solid).

A few versions with realistic numbers below :

. . .

125 fpsHz (8ms) minimum with multiFrameGen x4 version = between 135 fps and 145 fps post dlss quality upscale

To get 500fps solid after mFGen x4, where you'd no longer need vrr and wouldn't have varying frame render times, you'd need a 125fps solid . To achieve that solid, uninterrupted 125 fps, you would generally need to be between 135 fps and 145 fps average (post dlss quality upscale).

Click to expand...

. .

100 fpsHz (10ms) minimum with multFrameGen x5 version = between 120 to 140 fps average post dlss quality upscale

To ensure your frame rate never dips below 100 FPS, you need a native average of roughly 120 to 140 FPS. The specific number depends on the 1% lows and your hardware's frame-pacing consistency. [1, 2]
Because PC games experience sudden demand spikes (like when entering a new area or triggering an explosion), your "1% lows" will typically be 15 - 20 % lower than your average frame rate. [1, 2]

The Math Behind The Dips

The 80/20 Rule of Frame Variance: In modern PC gaming, the slowest 1% of your rendered frames (the Low metric) dictates when you "feel" stutters. If your average is 120 FPS, your 99th percentile frame rate is generally around 100 FPS. [1, 2]

The Target: If your target floor is 100 FPS, the math dictates that a 15% variance requires an average of approximately 117 FPS.

The Reality: To account for engine-level micro-stutters and sudden drops, most gamers aim for a 130 - 140 FPS average to completely eliminate sub 100 FPS dips.

Click to expand...

If you had post quality DLSS upscale frame rate of 120 (8.3ms). to 140 fps (7.14ms), you could multiply your 100fps (10ms) minimum x5 to 500fpsHz, or perhaps in the future x10 to 1000 fpsHz. Then no VRR necessary, 2ms persistence at 500fpsHZ, 1ms persistence (crt equivalent) at 1000 fpsHz.

You could keep running VRR optionally, too of course, if you wanted. Depending on the graph it might even reduce your effective lag slightly, but I'd keep an eye on the frame rate minimum in regard to the framerender latency "lag". I'd probably want my native framerender latency to be 10ms or less at the worst (low end of the graph), even if higher mFGen multiples are available eventually, and even if nvidia improves their latency tricks.

. . .

With flagship gpus, post dlss quality upscaling, 120 to 140fps is already doable on a good number of games, and that number increase a lot if you dial them in a bit (e.g. turn off path tracing). Future gens of gpus, perhaps even those a tier down from top, will be as powerful or more powerful in regard to native fps, too (and probably with better ai upscaling chips and software, maybe better path tracing performance, etc).

search result:

An estimated 25 to 30 popular modern PC games hit the 120fps to 140fps sweet spot at 4K resolution on an RTX 5090 using DLSS without Frame Generation. This subset primarily consists of extremely well-optimized or purely rasterized titles rather than extreme path-traced games.

Because of the sheer horsepower of the Blackwell architecture, modern games fall into distinct categories regarding the 120fps–140fps 4K target: [1]

Direct Hits (120fps–140fps): Popular titles that use rasterization or moderate ray tracing hit this exact window effortlessly at 4K using DLSS (Quality mode). Examples include Call of Duty: Black Ops 6, Battlefield 2042, Cyberpunk 2077 (with standard Ray Tracing, not Path Tracing), Marvel's Spider-Man 2, Hogwarts Legacy, and Forza Horizon 6. [1, 2, 3, 4, 5]

Overkill (>145fps): Highly competitive or lightweight esports titles—like Apex Legends, Overwatch 2, Counter-Strike 2, Valorant, and The Finals—vastly exceed 140fps even at native 4K or with DLSS. [, 2]

Under Target (<120fps): Next-gen, fully path-traced titles such as Cyberpunk 2077 (with Path Tracing enabled), Alan Wake 2, or Black Myth: Wukong demand extreme rendering loads. Even with an RTX 5090 and DLSS Super Resolution, these will naturally fall into the 60fps–85fps range without Frame Generation. [1, 2, 3, 4, 5] <--- you can turn off path tracing in their settings though, optionally

Click to expand...

.

XoR_ · May 30, 2026

After carefully thinking about this I came to the conclusion that the best summary to what FG is is single word: SCAM
It would not be and might have its use cases like these suggested by some people if it was reprojection. Otherwise trading latency for fake frames is just... ridiculous.

Like why would I even like such smooth motion?
Why wouldn't I like more cinematic look?

CRT doesn't make image overly smooth in an artificial way but makes motion sharp in an artificial way. That is something completely different. Incomparable.

jbltecnicspro · May 30, 2026

XoR_ said:
After carefully thinking about this I came to the conclusion that the best summary to what FG is is single word: SCAM
It would not be and might have its use cases like these suggested by some people if it was reprojection. Otherwise trading latency for fake frames is just... ridiculous.

Like why would I even like such smooth motion?
Why wouldn't I like more cinematic look?

CRT doesn't make image overly smooth in an artificial way but makes motion sharp in an artificial way. That is something completely different. Incomparable.

Not to mention you need even more hardware to support this. Meanwhile CRT just makes clear motion naturally.

Reject modernity. Embrace tradition.

elvn · May 30, 2026

. .

XoR_ · May 30, 2026

jbltecnicspro said:
Not to mention you need even more hardware to support this. Meanwhile CRT just makes clear motion naturally.

I wouldn't call strobing "natural".
Also needing more hardware... not an issue if we have hardware.

I just don't like these fake frames because the fake frames that we got are pretty bad because they make games more laggy.
When Oculus did frame gen I loved it because it solved the main issue. When my PC wouldn't keep up producing 90 frames per second I would get game running 45 fps and there would be more lag but I wouldn't feel that lag at all because what I interacted with and which was used for e.g. aiming would run at 90fps.

If we had proper reprojection frame gen and it would eliminate perceived latency instead of increasing it then flock yeah, let's all get excited about it.
And even then I wouldn't say it would be any reason why we don't need or want strobed displays or even that we should use it because it is always better to have more fps.

Sycraft · May 30, 2026

XoR_ said:
Like why would I even like such smooth motion?

Because it looks more realistic? Real life doesn't have a frame rate, if you follow a moving object with your eyes, it is clear and smooth. Well, get a high enough frame rate and that is what it looks like on a screen too. When you get in the 1000fps range, you are starting to talk completely imperceptible frames, the motion will just be smooth.

XoR_ said:
Why wouldn't I like more cinematic look?

That sounds like the "30 fps is enough for anyone" argument. Deciding that low FPS is the "right" was of doing things and then that we should use old tech to make it look less blurry. I mean if you want cinematic gaming I guess you can cap your framerate at 24fps, play on CRT or something else with strobing (actual film projectors generally strobe the whole image with a shutter at 72hz, not a line-by-line drawing like a CRT) and be happy.

You'll have to forgive me, and most of the rest of the world, if we don't want to join you though and wan tot enjoy high FPS gaming, and even just high FPS desktop.

XoR_ · Jun 1, 2026

If frame rate was something you chose in separation to anything else or something only limited by monitor then there is rarely any point to not using highest fps you can use.
In reality fps is not free lunch and FG is terrible compromise which causes massive input lag. In this case its better to just forego it and play with 'cinematic look'.
Of course even 120fps is more cinematic in how it looks compared to much higher fps.

elvn · Jun 4, 2026

multi frame gen lag is directly tied to your native frame rate. If you have a healthy frame rate on a higher resolution screen, dlss+multiFrameGen will work better, and cleaner, and with less effective lag. 100fps minimum (native) would be 10ms, which is what gaming tvs had at first, which is not "laggy".

. . . . . .

Online gaming servers, rather than LAN tournaments, have 128 tick rate at best, which is 7.8 ms per tick from server and the rate you send your local action state to the server. Once in awhile, a tick or a frame can arrive mid-tick or mid-frame on either end of the system though, causing an additional frame or tick delay when that happens.

In online gaming, for example on an optimized game - as long as you keep over 128fpsHz native as your minimum (post dlss upscale but pre-mFrameGen) - you will get something like 72ms of online "temporal gap". That "Temporal gap" thing in games is most obvious in things like "rubberbanding" at worst (happens more often on lower tick servers), and it's also experienced as, and more commonly known as, "peeker's advantage". It can also have the side effect of high fire-rate weapons in online games delivering it's high fire rate bullets packed all together as a "super bullet".

By comparison, if you had 60fpsHz solid, you'd get 100ms of that temporal gap. That would be worse throughout if those 128fpsHz or 60fpsHz were averages instead of minimums. It would also be worse for everyone when the tick rate of the server is worse than 128, which surprisingly many still are, some a lot worse.

Online gaming is not a 1:1 relationship to your local simulation. It's always got a temporal gap, it's just a matter of by how much and how noticeable that temporal gap is. It's sort of a "displacer beast", where what you are aiming at on your screen isn't even necessarily exactly where you think it is at any given time, as far as the server is concerned. .

. . . .

To get that optimal 128fpsHz minimum for playing on a 128 tick server :

To realistically maintain a 128 FPS minimum, your hardware should be pushing an average frame rate of 150 to 170 FPS (roughly 15-30% higher than your target). This headroom ensures that intense visual effects, crowded servers, or sudden frame drops do not push your performance below the crucial 128 FPS threshold.
Achieving this level of performance requires a capable setup, especially to prevent "1% lows" (the lowest 1% of frames measured during gameplay) from dipping below your target.

Why Target 128 FPS?

High-Refresh Gaming: 128 FPS perfectly complements 144Hz monitors, keeping gameplay fluid.

Engine-Specific Ticks: Many competitive titles (such as Apex Legends or VALORANT) and custom servers run on tick rates where syncing your FPS to multiples of 64 or 128 provides tighter, more responsive registration.

If you are still using VRR rather than setting a cutoff at your low end, then you might have a graph something like

(100 to 110 microstutter .1%) ... 128fpsHz lows <<<<..(150 to 170 fps) 160fpsHz average.............>>> 190 to 200 fpsHz (looking at walls, small rooms, etc)

( 10ms frame render lag) ... 7.8ms lows <<<<<..................................6.25 ms average............. >>>> 5.26ms to 5ms

. . . . .

In regard to online gaming, if you are that worried about input lag, then you should be worried about that server temporal gap and keeping your frame rate around 160fps native average (post DLSS upscale, but pre-multi-framegen) already for a 128 tick server. Therefore your dlss+MultiFrameGen render time lag should be pretty small as shown in ranges listed in the previous few lines above this.

Where people get obnoxious frame render lag from DLSS+mFrameGen is when they are trying to make a low native frame rate " a good number" (using framegen beyond what dlss can do), instead of making a good frame rate better. (and even with powerful gpus on certain games, keeping path tracing on, esp. at 4k rez) .

. . .

For local adventure games, and even very challenging souls/souls-like games where timing is critical - you could probably do 120 to 140 fps native and have decently low frame render lag, and appreciable motion definition gains.

If you had post quality DLSS upscale frame rate of 120 (8.3ms). to 140 fps (7.14ms), you could multiply your 100fps (10ms) minimum x5 to 500fpsHz, or perhaps in the future x10 to 1000 fpsHz. Then no VRR necessary, 2ms persistence at 500fpsHZ, 1ms persistence (crt equivalent) at 1000 fpsHz. That, or you could keep VRR on, and get the benefits of the whole graph's frame render time variance being at that 8.3ms to 7.14ms average.

With flagship gpus, post dlss quality upscaling, 120 to 140fps is already doable on a good number of games, and that number increase a lot if you dial them in a bit (e.g. turn off path tracing). Future gens of gpus, perhaps even those a tier down from top, will be as powerful or more powerful in regard to native fps, too (and probably with better ai upscaling chips and software, maybe better path tracing performance, etc).

search result:

An estimated 25 to 30 popular modern PC games hit the 120fps to 140fps sweet spot at 4K resolution on an RTX 5090 using DLSS without Frame Generation. This subset primarily consists of extremely well-optimized or purely rasterized titles rather than extreme path-traced games.

Because of the sheer horsepower of the Blackwell architecture, modern games fall into distinct categories regarding the 120fps–140fps 4K target: [1]

Direct Hits (120fps–140fps): Popular titles that use rasterization or moderate ray tracing hit this exact window effortlessly at 4K using DLSS (Quality mode). Examples include Call of Duty: Black Ops 6, Battlefield 2042, Cyberpunk 2077 (with standard Ray Tracing, not Path Tracing), Marvel's Spider-Man 2, Hogwarts Legacy, and Forza Horizon 6. [1, 2, 3, 4, 5]

Overkill (>145fps): Highly competitive or lightweight esports titles—like Apex Legends, Overwatch 2, Counter-Strike 2, Valorant, and The Finals—vastly exceed 140fps even at native 4K or with DLSS. [, 2]

Under Target (<120fps): Next-gen, fully path-traced titles such as Cyberpunk 2077 (with Path Tracing enabled), Alan Wake 2, or Black Myth: Wukong demand extreme rendering loads. Even with an RTX 5090 and DLSS Super Resolution, these will naturally fall into the 60fps–85fps range without Frame Generation. [1, 2, 3, 4, 5] <--- you can turn off path tracing in their settings though, optionally

Click to expand...

. . . . .

regarding something like a fw900 CRT :

Say you are running your Sony FW900 at 2304x1440 @ 80Hz, (or its optimal recommended widescreen resolution 1920x1200 at 85Hz)

If you want a sort -of modern rez, you are at 2304x1440 at 80fpsHz max, so you are much worse than the smallest "peeker's advantage" temporal gap that you could get on a 128tick online gaming server if you had a a screen that did over 128hz, like a 144hz screen or higher, (when you are keeping over 128fps as your lows on such a high hz screen, for example).
Your motion definition ~ pathing articulation/shaping, smoothness of motion, and even animation cycle states shown will also be lower, limited to 80fps, where you can obviously see appreciable gains at 120 - 240, and really I think likely up until at least 500fpsHz.
Worth noting that your local game "simulation" is not waiting around for the next tick, either... it's predicting and simulatiing frames of action states until the next adjudicated tick from the ultimate authority of the server hits, which may retcon reality some amount, depending on how it all resolves, and also the biased flavor of the server code. The more "behind" the tick rate you are, the more difference your local simulation might have to predict and "make up", so the more drawing outside of the lines it might be.

Google result:

╔════════════════════════════════════════════════╗
║ SERVER STATE (128-Tick Baseline) ║
║ Updates game data every 7.81 milliseconds ║
╚════════════════════════════════════════════════╝
│
┌────────────────────────┼──────────────────────────────┐
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 60 FPS Solid │ │ 80 FPS Solid │ │ 128 FPS Solid │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Render: 16.67 ms │ │ │ Render: 12.50 ms │ │ Render: 7.81 ms │
└──────────────────┘ └──────────────────┘ └──────────────────┘

Core Metrics Comparison

Metric 60 FPS Solid 80 FPS Solid 128 FPS Solid
Frame Delivery Time 16.67 ms 12.50 ms 7.81 ms
Ticks per Frame ~2.13 server ticks ~1.60 server ticks Exactly 1 server tick
Interpolation Window Heavy (Needs 2+ ticks) Moderate (Ticks drift) None (1:1 alignment)
Max Visual Delay ~17 ms behind server ~13 ms behind server ~8 ms behind server

The "Outside the Lines" Effect

60 FPS Solid: Heavy Smearing

The State: Your PC throws away more than half of the server's updates.

The Visuals: Heavy simulation. The client constantly guesses positions across two whole ticks.

The Result: You are drawing far outside the server lines. You see a smoothed path of where the enemy was, missing their sharpest direction changes.

80 FPS Solid: Jagged Drift

The State: The math is uneven (\(128 \div 80 = 1.6\)).

The Visuals: Unbalanced simulation. Frame 1 aligns with a tick, Frame 2 drops between ticks, Frame 3 lands on a completely different tick interval.

The Result: You draw closer to the lines, but the line thickness fluctuates. This creates micro-stuttering in visual information freshness.

128 FPS Solid: Perfect Tracing

The State: Absolute harmony (\(128 \div 128 = 1\)).

The Visuals: Zero simulation. Every single frame displays a brand-new, unique server update packet.

The Result: You draw perfectly inside the lines. What you see is exactly what the server calculates.

Gameplay Impact

Input Latency

60 FPS: Your clicks can wait up to 16.67 ms to register on your screen before sending to the server.

80 FPS: Latency drops to 12.50 ms. It feels snappier, but commands still bottle up between ticks.

128 FPS: Minimum possible latency (7.81 ms). Your mouse inputs slice cleanly into the server's update windows.

Hit Registration & "Ghost Misses"

60 FPS: High risk. You click an enemy head. On your screen, it aligns. On the server, that player already changed directions 8 ms ago. The server rejects your shot.

80 FPS: Medium risk. The desync window is smaller, but uneven frame times still cause occasional phantom misses on fast-moving targets.

128 FPS: Zero risk. If your crosshair is on the pixel, the server registers the hit. No spatial desync occurs.

. .

This is the peekers advantage / "temporal gap" breakdown again, which still happens ~ 72ms even when a best case scenario of over 128fps on a 128 tick server. Note that this assumes solid frame rate, so where it's an average, those ms will swing to the worse a bit throughout the graph when the fps is in the zones beneath 128.

╔═════════════════════════════════════════════════╗
║ AGGRESSIVE PEEKER APPROACHES ║
║ Clears the corner on a 128-Tick Server ║
╚═════════════════════════════════════════════════╝
│
┌───────────────────────────┼──────────────────────┐
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 60 FPS Holde r │ │ 80 FPS Holder │ │ 128 FPS Holder │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ Total Delay: │ │ Total Delay: │ │ Total Delay: │
│ ~100 ms │ │ ~85 ms │ │ ~72 ms │
└────────────────┘ └────────────────┘ └────────────────┘

Technical Delay Breakdown
This breakdown assumes a pristine network environment where both the peeker and the angle-holder have an identical 20 ms ping (10 ms one-way).

Delay Component 60 FPS Holder 80 FPS Holder 128 FPS Holder
Network Transit (Both Pings) 20.00 ms 20.00 ms 20.00 ms
Server Processing (1 Tick) 7.81 ms 7.81 ms 7.81 ms
Client Frame Time (GPU) 16.67 ms 12.50 ms 7.81 ms
Network Interpolation Buffer 23.43 ms (3 Ticks) 15.62 ms (2 Ticks) 7.81 ms (1 Tick)
Monitor Scan-Out & Input Lag ~32.00 ms ~29.00 ms ~28.00 ms
Total Peeker's Advantage ~100 ms ~85 ms ~72 ms

elvn · Jun 5, 2026

If interested in further reading, here are more details about what I called the "termporal gap", etc., explained again in detail by google. I find this kind of thing an interesting read, personally.

The technical umbrella term for this temporal gap is end-to-end netcode latency (or more broadly, network desynchronization), which is specifically comprised of client-side interpolation delay, tick interval/server processing delay, and frametime rendering latency. [1, 2, 3, 4, 5]
In game development, this specific mathematical calculation of human-perceptible delay is often referred to as the "Desync Window" or the "Window of Opportunity" mismatch. [1, 2]

. . .

Why the Gaps Happen (The Math)

The specific 72ms and 100ms gaps you mentioned are caused by a stacking pipeline of delays between your hardware and the server. The mathematical breakdown reveals how these numbers are reached: [1]

Network Interpolation (Interp Delay): Games like Counter-Strike or Valorant intentionally buffer enemy movement by 1 to 2 server ticks (typically 15.6ms on 128-tick servers) to smoothly animate players instead of letting them teleport.

Server Tick Rate Delay: A 128-tick server updates every 7.8ms.

Frametime Rendering Latency: Your computer must render the frame. At 128 FPS, a frame takes 7.8ms. At 60 FPS, a frame takes 16.6ms.

One-Way Network Ping: The unavoidable physical travel time for data packets. [1, 2, 3, 4, 5]

When a developer calculates the total temporal gap (assuming a standard competitive ping of around 30ms-40ms), the pipeline scales exactly to your examples: [1]

[60 FPS / 128 Tick Client] -> 16.6ms (FPS) + 15.6ms (Interp) + 7.8ms (Tick) + ~60ms (RTT) = ~100ms Gap
[128 FPS / 128 Tick Client] -> 7.8ms (FPS) + 15.6ms (Interp) + 7.8ms (Tick) + ~40ms (RTT) = ~72ms Gap

The Resulting Side Effects
When this end-to-end latency window becomes desynchronized, it produces the exact netcode phenomena you described:

Peeker's Advantage: The attacker moves around a corner and sees a stationary defender instantly on their local client. The defender remains blind until the attacker's position packet travels through the netcode latency pipeline to the server and back down to the defender. [1, 2, 3, 4]

Super Bullets: If an enemy fires three fast shots, the server bundles those incoming packets together. Because of the temporal gap, your client receives all three hit updates in a single tick, making it feel like you died to one impossibly high-damage "super bullet." [1]

Rubberbanding: Your local client predicts your movement instantly, but a packet drop or extreme delay causes the server to reject your position. The server forcefully snaps your character back to its last validated state. [1, 2]

. . .

The comprehensive technical term for this temporal gap is end-to-end netcode latency [1]. In game development, the resulting mismatch between players is called the desynchronization window.
This gap is not caused by one single factor [1]. It is a stacking pipeline of delays combining your computer's hardware speed, network transit times, and server processing rules [1].

The Stacking Pipeline (How the Math Works)
To understand the breakdowns below, you must first look at the four specific components that build the temporal gap [1]:

Frametime Rendering Latency: The time it takes your graphics card to draw a frame [1]. Higher frame rates (FPS) mean lower rendering latency [1].

Client-Side Interpolation Buffer (Interp): To prevent enemy players from teleporting or stuttering, modern engines intentionally delay enemy animations on your screen by exactly 2 server ticks (15.6ms on a 128-tick server) to ensure smooth visual movement [1].

Server Tick Interval Delay: A 128-tick server updates the game world every 7.8ms [1]. Data can wait up to this long to be processed.

Network Round Trip Time (RTT): The physical travel time for data packets moving from your PC, to the server, and back [1].

. . .

Full Comparative Breakdown: 60 FPS vs. 80 FPS vs. 128 FPS
Below is the exact mathematical stacking of delays for each frame rate on a competitive 128-tick server.

1. The 60 FPS Baseline (~100ms Total Gap)
At 60 FPS, your hardware creates a bottleneck because it cannot keep pace with the high-frequency 128-tick server.

Frametime Latency: 16.6ms

Interpolation Delay: 15.6ms

Server Tick Delay: 7.8ms

Network RTT (Ping): ~60.0ms

The Math: 16.6ms + 15.6ms + 7.8ms + 60.0ms = 100.0ms

2. The 80 FPS Mid-Tier (~87ms Total Gap)
Upgrading to 80 FPS shaves 4.1ms off your rendering latency, narrowing the desynchronization window.

Frametime Latency: 12.5ms

Interpolation Delay: 15.6ms

Server Tick Delay: 7.8ms

Network RTT (Ping): ~51.1ms

The Math: 12.5ms + 15.6ms + 7.8ms + 51.1ms = 87.0ms

3. The 128 FPS Match (~72ms Total Gap)
At 128 FPS, your frame rate matches the server's tick rate perfectly, minimizing the hardware bottleneck.

Frametime Latency: 7.8ms

Interpolation Delay: 15.6ms

Server Tick Delay: 7.8ms

Network RTT (Ping): ~40.8ms

The Math: 7.8ms + 15.6ms + 7.8ms + 40.8ms = 72.0ms

How These Gaps Create In-Game Phenomena

[60 FPS Client] -------- (100ms Window) --------> [128-Tick Server]
[80 FPS Client] ------ (87ms Window) -------> [128-Tick Server]
[128 FPS Client] ---- (72ms Window) ----> [128-Tick Server]

When these total temporal windows mismatch between players, it triggers the engine's lag compensation systems, producing distinct visual errors:

Peeker's Advantage: If a 128 FPS player swings around a corner into a 60 FPS player, the 128 FPS player has a much smaller temporal gap [1]. They will see the stationary 60 FPS defender instantly [1]. The defender remains completely blind until the attacker's data clears the defender's larger 100ms latency pipeline [1].

Super Bullets: A 128-tick server updates twice as fast as a 60 FPS monitor can display images. If an enemy fires multiple shots rapidly, the server processes them across separate ticks. However, because your 60 FPS or 80 FPS monitor cannot display those updates fast enough, multiple server updates hit your client during a single frame render [1]. This compresses the damage into one frame, making it feel like you died to a single, impossible "super bullet" [1].

Rubberbanding: If your total pipeline stalls due to a packet drop, your local client continues to predict your movement forward. When the connection resumes, the server evaluates your position based on the delayed temporal gap. If the server rejects your position, it forcefully snaps your character back to its last validated server location [1].

. . .

On your own screen, your crosshair is almost perfectly in sync in every example because of a netcode trick called lag compensation (rewinding time). However, when comparing your screen to the absolute "true present" of the server, the server is desynchronized by exactly the temporal gaps we calculated (72ms to 100ms). [1, 2, 3]

The Reference Baselines
To contextualize the online examples, look at how little lag exists when network constraints are removed entirely: [1]

1. Single Player Games (0ms Server Desync)
In a single-player game, your PC is the server. There is zero network transmission. The only delay is your hardware's input lag and frametime rendering latency. If you are playing at 128 FPS, what you see on screen is mathematically identical to what the game logic processes, missing only a tiny 7.8ms rendering window. [1, 2, 3]

2. LAN Competitions (~1ms to 5ms Server Desync)
In a pro LAN tournament, the players and the server are in the same room connected via high-speed ethernet switches. [1]

The Network Delay: Physical network transit drops from 40ms–60ms down to a nearly invisible 1ms or less.

The Sync Mismatch: Pro LAN setups mandate incredibly high frame rates (e.g., 360Hz+ monitors running at 400+ FPS). Interpolation delays are manually turned down by developers. The server and the local monitor are out of sync by less than 10ms total. This is why LAN gameplay feels unbelievably crisp; players are essentially interacting with the exact same millisecond of reality. [1, 2, 3]

Online Matchmaking: The "Time Travel" Illusion
Online, things shift dramatically. If the server only checked where an enemy was at the exact millisecond your packet arrived, you would miss every shot. In the 100ms it takes a 60 FPS player's packet to clear the gap, a running opponent moves roughly half a foot across the map. [1]
To fix this, modern engines like Counter-Strike or Valorant use Lag Compensation. Every time you click your mouse, the server looks at your specific temporal gap, rewinds its clock backward in time, and checks: "Where was the enemy's hitbox exactly 72ms (or 100ms) ago on this specific player's screen?" [1, 2, 3]
Because of this "time travel" feature, here is exactly how desynchronized the server is for each frame rate:

Metric [1, 2, 3, 4, 5, 6, 7]	60 FPS-Hz Client	80 FPS-Hz Client	128 FPS-Hz Client	LAN Tournament	Single Player
Server Desync Window	~100ms behind	~87ms behind	~72ms behind	~5ms to 10ms behind	0ms (Perfect Sync)
What Your Screen Sees	Past state of the match	Closer past state	Closest to online state but still behind	The functional present	The absolute present
Server's Action	Rewinds time 100ms to check your crosshair.	Rewinds time 87ms to check your crosshair.	Rewinds time 72ms to check your crosshair.	Micro-rewinds time (<10ms).	Instantly applies damage.

The Practical Cost of Each Gap
Even though lag compensation ensures that clicking a head on your screen grants you the kill, a larger desync window leaves you highly vulnerable to server discrepancies:

At 60 FPS (100ms Desync): You are looking 100ms into the past. If an enemy running behind a wall shoots you on their screen, the server will accept their shot. On your screen, you might have already made it two steps behind solid brick cover. The server rewinds, validates the enemy's shot from 100ms ago, and you die behind a wall. [1]

At 80 FPS (~87ms Desync): You are operating roughly 13ms closer to the server's true present than a 60 FPS player. While your frame processing time improves slightly, you still face a noticeable delay that allows aggressive enemies to take advantage of peeker's priority during fast corners. [1]

At 128 FPS (72ms Desync): You are operating 28ms closer to the server's true present than the 60 FPS player. The window for you to get "shot behind a wall" or suffer from peeker's advantage drops significantly. [1]

On LAN (<10ms Desync): Dying behind a wall is virtually impossible. Peeker's advantage disappears because the defender's screen updates almost simultaneously with the attacker's physical keystroke.

. . .

80 fpsHz player vs 128fpsHz player on 128 tick server:

Highlights..

Fluctuating wait time means your input latency to the server is constantly changing by up to 7.8 ms from one millisecond to the next. This causes microscopic variations in when your shots register on the server.
A 128 FPS enemy moving around a corner updates the server every 7.81 ms. If they see you, their action registers instantly on the next server tick. Your client only updates every 12.5 ms, meaning you will see them step around the corner up to 4.7 ms later than a player with matching high-tier hardware.
The Sub-Tick / Interp Trap: Modern engines use interpolation to smooth out the gaps between your 12.5 ms frames. This creates a visual lie: your screen shows an enemy moving smoothly, but their actual hitbox on the server is already steps ahead because the server is calculating physics nearly twice as fast as your monitor can show them.

Running 80 FPS at 80 Hz against a 128-tick server creates an asynchronous relationship where your local hardware and the server are constantly drifting out of alignment. Because their update cycles do not divide evenly, your temporal gap changes from frame to frame, resulting in micro-stuttering and varying desync against other players.

1. The Fundamental Mathematical Misalignment
Your monitor and game engine refresh at a different pace than the server processes information:

Your Hardware Loop (80 FPS / 80 Hz): Generates and displays a new frame every 12.5 ms (1000 ms / 80).

The Server Loop (128-Tick): Updates the entire simulation world every 7.8125 ms (1000 ms / 128).

2. The Temporal Gap Over Time
Because 12.5 ms is not a clean multiple of 7.8125 ms, your client and the server continuously drift.

Frame-by-Frame Interleaving
Over a 100 ms window, the server processes 12.8 ticks while your PC renders 8 frames. Your local engine has to package your inputs and send them to the server on this mismatched schedule:

Frame 1 (12.5 ms): Arrives right after Server Tick 1 (7.81 ms), sitting idly for 3.12 ms before Server Tick 2 (15.62 ms) processes it.

Frame 2 (25.0 ms): Arrives just before Server Tick 3 (23.43 ms), meaning it misses that tick and waits 6.25 ms for Server Tick 4 (31.25 ms).

Frame 3 (37.5 ms): Perfectly aligns with Server Tick 5 (39.06 ms) with almost zero idle wait time.

The "Jitter" Effect
This fluctuating wait time means your input latency to the server is constantly changing by up to 7.8 ms from one millisecond to the next. This causes microscopic variations in when your shots register on the server.

3. Interaction with the Server
Because your hardware is slower than the server (12.5 ms vs. 7.81 ms), your PC cannot feed the server data fast enough.

Packet Starvation: The server expects an update every 7.81 ms. Because you only generate data every 12.5 ms, the server experiences "empty" ticks where it receives no new input from you.

Server Side Extrapolation: During those empty ticks, the server must predict or freeze your movement vector based on your last known frame. When your next packet arrives, the server abruptly snaps your true position into place.

4. Interaction with Other Players (The Desync Penalty)
When fighting another player (especially one playing at a synchronized 128+ FPS), the mismatched temporal gaps hurt your responsiveness.

Timeline (ms): 0 ------- 7.81 ------- 12.5 ------- 15.62 ------- 23.43 ------- 25.0
128-Tick Server: [Tick 0] [Tick 1] [Tick 2] [Tick 3]
128 FPS Enemy: [Frame 0] [Frame 1] [Frame 2] [Frame 3]
80 FPS You: [Frame 0] [Frame 1] [Frame 2]

Peeker's Disadvantage: A 128 FPS enemy moving around a corner updates the server every 7.81 ms. If they see you, their action registers instantly on the next server tick. Your client only updates every 12.5 ms, meaning you will see them step around the corner up to 4.7 ms later than a player with matching high-tier hardware.

The Sub-Tick / Interp Trap: Modern engines use interpolation to smooth out the gaps between your 12.5 ms frames. This creates a visual lie: your screen shows an enemy moving smoothly, but their actual hitbox on the server is already steps ahead because the server is calculating physics nearly twice as fast as your monitor can show them.

Restatement of the Result
The mathematical relationship between 80 FPS / 80 Hz and a 128-tick server results in asynchronous packet delivery, creating a shifting temporal gap of up to 7.81 ms every frame that gives a distinct physical and registration advantage to players running at matching or higher frame rates.

. . .

The Cover Mismatch (Dying Behind Walls)
Imagine you are running behind a solid brick wall to escape an enemy. The enemy shoots at your last visible position. Here is how your framerate dictates your vulnerability to being killed when you think you are completely safe:

1. The 60 FPS Player (100ms Desync Window)

The Scenario: You safely make it two full steps behind the brick wall on your monitor and relax.

The Cost: Because your temporal gap is 100ms, you are seeing the game world a tenth of a second late. On the server's true timeline, you are still exposed in the open doorway. The enemy shoots you. The server rewinds its clock 100ms, validates that the enemy hit your past "ghost," and you instantly drop dead despite being completely hidden on your screen.

2. The 80 FPS Player (87ms Desync Window)

The Scenario: You dive behind the brick wall and make it about one full step into safety.

The Cost: By gaining 20 FPS, you shave 13ms off your delay compared to the 60 FPS baseline. You are operating slightly closer to the server's present. You will still experience getting shot behind the wall, but the visual discrepancy is tighter. You will die just as you cross the threshold of the wall, rather than two steps deep into safety.

3. The 128 FPS Player (72ms Desync Window)

The Scenario: Your frame rate matches the server, minimizing your local hardware delay.

The Cost: Operating at a 72ms gap means you are viewing the closest possible version of online reality. When you run behind cover, your screen and the server are highly aligned. If you get shot, it happens exactly as your heel clears the corner, making the death feel much more fair and responsive. (edit by elvn : but you still died unfairly compared to what your local simulation displayed due to the termporal gap, you just might feel less "robbed" because it's a closer call).

4. The LAN Tournament Player (<10ms Desync Window)

The Scenario: You play on zero-latency physical hardware and local network switches.

The Cost: There is virtually no practical cost. Getting shot behind a wall is physically impossible. If you make it behind cover on your screen, you made it behind cover on the server. Gameplay is completely transparent, and raw human reaction time is the only deciding factor.

Summary of Competitive Disadvantages:

Feature	60 FPS-Hz Client (100ms)	80 FPS-Hz Client (87ms)	128 FPS-Hz Client (72ms)	LAN Player (<10ms)
"Dying Behind Walls" Severity	High (Dying multiple steps past cover)	Moderate (Dying just inside cover)	Low (Dying at the exact edge of cover)	Non-Existent (True synchronization)
Peeker's Advantage Vulnerability	Defending is highly punishing	Defending is slightly more manageable	Optimal online defense window	No artificial advantage for the peeker
Visual Desync Penalty	Forced to play 28ms further in the past than a 128 FPS opponent.	Forced to play 15ms further in the past than a 128 FPS opponent.	Baseline standard for competitive online play.	Absolute absolute real-time reality.

. . .

elvn · Jun 6, 2026

When those breakdowns said single player 0ms "perfect sync", you are still subject to local frame rendering lag delaying how often you see scene states / action updates, and at lower fpsHz your motion definition / pathing articulation / smoothness / # of animation frames will be lower. That native frame rate also affects how you experience effective input lag when using frame generation.

google result breaking it down:

......................................................................................

Rendering Latency (without frame gen / multi frame gen)

Render latency is fundamentally tied to the time it takes for a single frame to be processed by your hardware. Because games experience performance fluctuations, average rates will result in frame time variance (such as 1% and 0.1% lows) causing noticeable microstutters. [1, 2, 3, 4, 5]

Target Average Rate (FPS / Hz) [1, 2]	Average Frame Latency	High Latency (0.1% Low Spikes)	Low Latency (Best Case/Cap)
1000 fps @ 1000 Hz	1.00 ms	2.50 ms - 5.00 ms	0.50 ms- 0.70 ms
480 fps @ 480 Hz	2.08 ms	4.00 ms - 8.00 ms	1.20 ms - 1.50 ms
165 fps @ 165 Hz	6.06 ms	12.00 ms - 15.00 ms	3.50 ms - 4.50 ms
144 fps @ 144 Hz	6.94 ms	15.00 ms - 20.00 ms	4.00 ms - 5.00 ms
120 fps @ 120 Hz	8.33 ms	20.00 ms - 25.00 ms	5.00 ms - 6.00 ms
80 fps @ 80 Hz	12.50 ms	30.00 ms - 40.00 ms	8.00 ms - 10.00 ms
60 fps @ 60 Hz	16.67 ms	35.00 ms - 50.00 ms	11.00 ms - 13.00 ms

Note: Real-world latency numbers—specifically "PC Latency" as measured by tools like the NVIDIA Developer PCL Pipeline Guide—include your input queues, engine simulation, and render queue, which can push actual display lags higher than raw frame times. For stable latency, gamers often cap their frame rates slightly below their monitor's refresh rate using utilities like the NVIDIA Reflex Latency Optimization Guide to prevent frame queuing

. .

=====================================================

Understanding the FrameGen Latency Paradox

If your monitor is displaying a silky-smooth 480 fps, but your engine's true, un-generated baseline performance is only 120 fps, your hands will experience the 8.33 ms average input responsiveness of 120 fps (plus a small interpolation overhead penalty). You are getting the visual smoothness of the high rate, but the mechanical delay of the lower rate. [1, 2, 3]
To counter this penalty, NVIDIA strictly mandates NVIDIA Reflex whenever Frame Generation is enabled. Reflex removes the traditional CPU-GPU render queue to drastically offset the structural lag. [1, 2]

.

Frame Generation Latency Breakdown

Below is a breakdown mapping the real-world impact of Multi-Frame Generation (assuming standard 2x generation, and the newer 4x/5x multipliers used in modern dynamic MFG): [1]

test version of that:

Visual Output (Monitor) True Base Game Loop Input Responsiveness Tied To Real-World Feel & Penalty
1000 Hz / 1000 fps 250 fps Native (via 4x MFG) ~4.00 ms base loop Excellent. The base frame rate is so high that the 1-frame buffering delay is virtually imperceptible.
480 Hz / 480 fps 120 fps Native (via 4x MFG) ~8.33 ms base loop Very Good. Highly responsive for single-player immersion, though still avoided by top-tier competitive esports players.
480 Hz / 480 fps 240 fps Native (via 2x MFG) ~4.17 ms base loop Extremely Sharp. Visually fluid, with the underlying input lag matching a native 240 Hz experience.
165 Hz / 165 fps 82 fps Native (via 2x MFG) ~12.20 ms base loop Good. Totally fine for casual gaming, but you will notice a tiny desync between mouse movements and camera panning.
144 Hz / 144 fps 72 fps Native (via 2x MFG) ~13.89 ms base loop Acceptable. Feels slightly heavier than a true native 144 fps, but completely playable thanks to Reflex.
120 Hz / 120 fps 60 fps Native (via 2x MFG) ~16.67 ms base loop The Baseline Sweet-spot. Matches the responsiveness of a native 60 fps console game but looks like 120 fps on screen.
60 Hz / 60 fps 30 fps Native (via 2x MFG) ~33.33 ms base loop Poor / "Quicksand" Effect. Avoid this. The engine takes too long to register inputs, making the generated frames feel deeply laggy and latent.

*note that if those numbers are frame rate averages, then if you allow your frame rate graph to run +/- 15% or so of that, rather than those numbers being your minimum ( .1% ) fps or at least your 10% lows - you may experience worse lag overall than those numbers.

===========================================================

Some comments from me:

160 FPS average for 128 tick servers (and/or single player games)
-------------------------------------------------------------------------------------------------

---- You could run a native graph like this, which would be enough to maximize your relationship to a 128tick server, and would be good for single player games, too.

100 to 110 microstutter .1%) ... 128fpsHz 10% lows <<<<..(150 to 170 fps) 160fpsHz average.............>>> 190 to 200 fpsHz (looking at walls, small rooms, etc)

( 10ms frame render lag) ............... 7.8ms lows <<<<<..................................6.25 ms average............... >>>> 5.26ms to 5ms

If you want more blur reduction and motion definition via multi frame gen on top of that

160 fpsHz average mFrameGen x2 = 320 fpsHz (average),
160 fpsHz average mFrameGen x4 = 640 fps Hz (average)

Maybe x5 some-year on better frame gen and gpus, ai chips.. ---> 800 fpsHz, or perhaps even higher up in multiples

.

A 120 to 140fps native option for single player games
-----------------------------------------------------------------------------

120 to 140fps average native option for single player games, which is achievable on a lot of games at 4k with a flagship gpu, and probably more gpus tiers on future gpus, plus more game titles even currently when you lower game settings a bit, e.g. turn off path tracing as necessary for some at 4k (or with 1440p screens, this is achievable on a lot more games and more gpu hardware tiers) .

The multi frame gen is based on your native frame rate, the "Avg Latency" in the chart below, but when running a frame rate average, you have to look at the lower end, too, like the range between 10% lows and that avg.

120 fpsHz average mFrameGen x2 = 240 fpsHz , x4 = 480 fpsHz (average)
140 fpsHz average mFrameGen x2 = 280 fpsHz, x4 = 560 fpsHz (average)

|..........FPS...............|.....Avg Latency....|........10% low Latency....... .|......High (0.1% Spikes).......|........Low (Best Case)
+-------------------------+------------------------+----------------------------------------+------------------------------------+-----------------------------------+
|.......60 FPS.............|........16.67 ms.......|........24.00ms - 28.00ms.........|......35.00 ms - 50.00 ms.......|.......11.00 ms - 13.00 ms
|.......80 FPS.............|........12.50 ms.......|........18.00ms - 22.00ms.........|......30.00 ms - 40.00 ms.......|.........8.00 ms - 10.00 ms
|................................|..............................|................................................|.............................................|..........................................
|.......120 FPS........ ..|.........8.33 ms........|........12.00ms - 14.50ms.........|......20.00 ms - 25.00 ms.......|.........5.00 ms - 6.00 ms
|.......140 FPS...........|.........7.14 ms........|........10.50ms - 12.50ms.........|......16.00 ms - 22.00 ms.......|.........4.50 ms - 5.50 ms
|.......160 FPS...........|.........6.25 ms........|..........9.00ms - 11.00ms.........|......13.00 ms - 18.00 ms.......|.........3.80 ms - 4.80 ms

.

XoR_ · Jun 8, 2026

The only lag that matters to me personally is hand movement vs how camera changes because it is what causes motion sickness. Kinda like in VR but a bit less because immersion is not as immediate - much harder to dissociate yourself from game world in VR. And is hard to immerse myself when everything lags and why input/display lag is so bad for games. Then in the game if there is slight delay it doesn't really matter that much.

FG tech (and display tech also!) should follow example from VR.
FG in VR is based on reprojection and viewport is calculated quickly before sending to displays thus how long game takes to render doesn't matter and you get absolutely latest state from sensors.
For frame generation it is harder to predict frame than just interpolate frames and this will inevitably lead to more visual artifacts but I would still take VR-like FG over current FG any time of the day and only such tech could be touted to me as replacement of real frames - still fake frames and if Jensen advertised it as performance boosting tech I would call it a scam but it would at least be usable.

Roen · Jun 9, 2026

There's technical limitations to CRT technology that makes it impossible to achieve the kind of high resolution and refresh rates that we have on LCDs and OLEDs.

A cathode ray tube has to "shoot at" the phosphor layer one dot at a time, one row at a time, aimed with a magnetic field. A high refresh rate at a high resolution demands extreme speed AND accuracy of that process. A process that is inherently either fast or accurate, not both.

The higher the resolution the faster it needs to fire to achieve the same refresh rate in order to finish drawing all those dots before the next refresh, as a result of the speed it can't be as accurate and starts to blur the image. The higher the refresh rate the faster it needs to fire at the same resolution, the more inaccurate it gets and blurs the image. To keep the image sharp at higher resolutions you have to lower the refresh rate. To keep the image sharp at high refresh rate you have to lower the resolution.

As far as I'm aware "we" never found a way to get around this fundamental problem which means CRTs can't be made at high enough resolution to make them large enough. This is why CRTs never got as big or as high resolution as today's flat panels.

I've had ChatGPT run the numbers for me a while ago. You'll have to excuse me for not remembering the numbers but it's staggering how fast it would need to be for modern resolutions and refresh rates. If you do the math and compare it to the max speed a tube can achieve before it becomes too inaccurate, it becomes painfully clear why CRT is dead. It's not just a little too slow it's orders of magnitude too slow.

Edit:
You might think making it larger would reduce the demand on accuracy so let's do some math and related logic with the help of AI again, one of the few things it's actually good at, and examine why making the CRT larger doesn't fix the accuracy limitations vs speed.

Suppose you want:

3840 × 2160 (4K)
240 Hz refresh

That's about:

8.3 million pixels/frame
× 240 frames/s
≈ 2 billion pixels/s

The CRT beam must position itself correctly and set the brightness for each pixel in 1/(2x10^9) = 0.5 nanoseconds. Even if you make the tube twice as large, you're still asking the beam to hit billions of distinct positions every second.

Why making the CRT larger doesn't solve it:
A larger screen means larger deflection angles, longer travel distances. The beam must sweep a greater area. The deflection system has inductance, so changing beam direction takes finite time. Faster scanning requires larger currents changing more rapidly, which becomes increasingly difficult. So a bigger tube can actually make high-speed deflection harder.

To achieve higher resolution, the beam spot must be tiny. Making the screen larger while keeping the same resolution means each pixel becomes physically larger, which helps somewhat. But if you increase both screen size and resolution proportionally (which is usually what people want), the beam spot must remain just as small.

Brightness
At very high refresh rates, each phosphor dot is illuminated for an extremely short time. To keep the image bright, you increase beam current.
But higher beam current causes stronger electron-electron repulsion ("space charge"), which enlarges the spot, reduces focus, and lowers resolution.
- More current → brighter image
- More current → blurrier image

Bandwidth requirements explode
The video amplifier must vary beam intensity at the pixel rate. For multi-gigapixel-per-second scanning, the CRT electronics need gigahertz-class bandwidth. The larger tube doesn't reduce this requirement. The beam still has to turn on and off accurately billions of times per second.

What a larger CRT does help with:
1920×1080 on a 40-inch CRT is easier than on a 10-inch CRT because pixels are physically larger.
But if the goal is:

"Can I get arbitrarily high resolution and refresh rate by just scaling up the CRT?"

The answer is no.

I loved the motion clarity and response of CRTs, my match performance in competitive Unreal Tournament 1999 (playing in some of the highest ranked teams, with and against Europe's top players..) dropped off significantly with the switch to 60Hz LCD at the time, but unfortunately the tech is simply not capable of meeting today's demands for resolution, size and refresh rate.

So... a debate about CRT vs LCD/OLED is utterly pointless. The tech can't be used for what you want. Nobody praising CRT wants to play games on something that's small, low res and/or low refresh rate. At least outside of an intentional "retro gaming" session.

To answer the OP's question directly:
"Would a modern CRT make any sense?"

I mean considering 4k resolutions, high refresh rates and large 16:9 screens. Would a 27 inch model be realistic?

No. Because such a thing isn't possible to make.

You can go back to your regular lives now and stop debating latency details - something the OP didn't ask about or mention in any way - as a sub-debate to the CRT question that's been dead and buried for years to those who already knew about the limitations. If you want the least latency in a modern monitor use an OLED, instead of an LCD and cap your fps to keep the GPU ~4% below max load (game engines don't always manage 100% uncapped, so I'm assuming 98% and subtract 2%). And use a mouse with a high polling rate. That's what's practical that you can do to affect that. Getting lost in latency math isn't going to help your latency and certainly won't bring back CRTs.

XoR_ · Jun 9, 2026

The faster you go the less effects such as electrons repelling eachother which defocus beam happen so scaling the beam wouldn't be that big of an issue.
Bandwidth-wise we already got to 400MHz-esque levels of video bandwidth going from VGA card to CRT through VGA cable as analog signals and then signal had to bounce around on CRT motherboard but today it would make sense to put everything much closer to the signal destination so tube neck. Amplifiers today can be made smaller and more powerful and less noisy. I mean we have digital signal and can put D/A conversion right before it is needed reducing blurring due to bandwidth.

Horizontal deflection coils would need to be beefed up for sure. I would assume that at some point trying to keep 31KHz compatibility would become too big of a burden so it would be dropped focusing really on high horizontal refresh - and tuning for this would make whole design more optimal.

The main question is how tight we could make shadow mask / aperture grille to squeezing high resolution.
What we did get would already look unreal to anyone from the beginning of early color CRT and its not like there is any indication we have already hit absolute limits of physics.
In fact I would say CRT as display tech was phased out right when we saw biggest development in this area.

Size-wise we don't talk beating modern TVs but CRTs already were made and sold at sizes which we use in monitor space.
Of course 32 inch CRT and especially if you made it deeper to avoid negative effects of having CRT tube too short would take massive amount of desk space. Someone who could afford such CRT can certainly afford big desk

Technically it would be hoverer possible to pull off. Like I said we already had 32 inch HD CRTs and with better shadow masks, much better electronics, etc. it should be possible to get some pretty amazing resolution out of such monitor.

There would be a limit to resolution but even if you had to drop resolution a bit (e.g. 1080 lines for 480Hz) then who cares? It would still look absolutely amazing.

---------
I see no technical limitations to make much better CRTs than we had.
Of course at some point such race wouldn't be viable and the moment OLEDs get proper strobing its game over.
Especially since VRR + strobing is a real possibility on OLED and/or other similar flat panel technologies.
VRR on CRT I don't really see being viable. If there are technical limitations to making VRR non-flicker on OLEDs I don't see VRR on CRT in any shape or form.

Roen · Jun 9, 2026

XoR_ said:
scaling the beam wouldn't be that big of an issue

Then what are you waiting for? Call Samsung or LG, you'll be a millionaire!

Nobu · Jun 9, 2026

I'm pretty sure we could do it. If we don't have the technology I'm certain it could be developed. I'm also certain it would not be cheap to manufacture, and I'm not certain it would be better. Those are probably the primary reasons it hasn't been done.

This is one of those things where you will have to develop it, you will have to secure big funding to get started, and you will have to be able to show everyone how much better it is than relatively cheap, already available technology. And then hope something better doesn't come around before you get product on shelves.

sharknice · Jun 9, 2026

Roen said:
There's technical limitations to CRT technology that makes it impossible to achieve the kind of high resolution and refresh rates that we have on LCDs and OLEDs.

A cathode ray tube has to "shoot at" the phosphor layer one dot at a time, one row at a time, aimed with a magnetic field. A high refresh rate at a high resolution demands extreme speed AND accuracy of that process. A process that is inherently either fast or accurate, not both.

The higher the resolution the faster it needs to fire to achieve the same refresh rate in order to finish drawing all those dots before the next refresh, as a result of the speed it can't be as accurate and starts to blur the image. The higher the refresh rate the faster it needs to fire at the same resolution, the more inaccurate it gets and blurs the image. To keep the image sharp at higher resolutions you have to lower the refresh rate. To keep the image sharp at high refresh rate you have to lower the resolution.

As far as I'm aware "we" never found a way to get around this fundamental problem which means CRTs can't be made at high enough resolution to make them large enough. This is why CRTs never got as big or as high resolution as today's flat panels.

View attachment 808153

I've had ChatGPT run the numbers for me a while ago. You'll have to excuse me for not remembering the numbers but it's staggering how fast it would need to be for modern resolutions and refresh rates. If you do the math and compare it to the max speed a tube can achieve before it becomes too inaccurate, it becomes painfully clear why CRT is dead. It's not just a little too slow it's orders of magnitude too slow.

Edit:
You might think making it larger would reduce the demand on accuracy so let's do some math and related logic with the help of AI again, one of the few things it's actually good at, and examine why making the CRT larger doesn't fix the accuracy limitations vs speed.

Suppose you want:

3840 × 2160 (4K)

240 Hz refresh

That's about:

8.3 million pixels/frame

× 240 frames/s

≈ 2 billion pixels/s

The CRT beam must position itself correctly and set the brightness for each pixel in 1/(2x10^9) = 0.5 nanoseconds. Even if you make the tube twice as large, you're still asking the beam to hit billions of distinct positions every second.

Why making the CRT larger doesn't solve it:
A larger screen means larger deflection angles, longer travel distances. The beam must sweep a greater area. The deflection system has inductance, so changing beam direction takes finite time. Faster scanning requires larger currents changing more rapidly, which becomes increasingly difficult. So a bigger tube can actually make high-speed deflection harder.

To achieve higher resolution, the beam spot must be tiny. Making the screen larger while keeping the same resolution means each pixel becomes physically larger, which helps somewhat. But if you increase both screen size and resolution proportionally (which is usually what people want), the beam spot must remain just as small.

Brightness
At very high refresh rates, each phosphor dot is illuminated for an extremely short time. To keep the image bright, you increase beam current.
But higher beam current causes stronger electron-electron repulsion ("space charge"), which enlarges the spot, reduces focus, and lowers resolution.
- More current → brighter image
- More current → blurrier image

Bandwidth requirements explode
The video amplifier must vary beam intensity at the pixel rate. For multi-gigapixel-per-second scanning, the CRT electronics need gigahertz-class bandwidth. The larger tube doesn't reduce this requirement. The beam still has to turn on and off accurately billions of times per second.

What a larger CRT does help with:
1920×1080 on a 40-inch CRT is easier than on a 10-inch CRT because pixels are physically larger.
But if the goal is:

The answer is no.

I loved the motion clarity and response of CRTs, my match performance in competitive Unreal Tournament 1999 (playing in some of the highest ranked teams, with and against Europe's top players..) dropped off significantly with the switch to 60Hz LCD at the time, but unfortunately the tech is simply not capable of meeting today's demands for resolution, size and refresh rate.

So... a debate about CRT vs LCD/OLED is utterly pointless. The tech can't be used for what you want. Nobody praising CRT wants to play games on something that's small, low res and/or low refresh rate. At least outside of an intentional "retro gaming" session.

To answer the OP's question directly:
"Would a modern CRT make any sense?"

No. Because such a thing isn't possible to make.

You can go back to your regular lives now and stop debating latency details - something the OP didn't ask about or mention in any way - as a sub-debate to the CRT question that's been dead and buried for years to those who already knew about the limitations. If you want the least latency in a modern monitor use an OLED, instead of an LCD and cap your fps to keep the GPU ~4% below max load (game engines don't always manage 100% uncapped, so I'm assuming 98% and subtract 2%). And use a mouse with a high polling rate. That's what's practical that you can do to affect that. Getting lost in latency math isn't going to help your latency and certainly won't bring back CRTs.

They could do multiple beams. There was some research and patents for it, but it was when LCD started emerging so it was abandoned.

You could imagine something like 4 CRTs combined into one giant glass screen and now you can do 4X the resolution. Or maybe a ton of tiny ones drawing their own little sections, or interlacing each other. There are all sorts of things they could try.

I doubt anything would be as viable as what LCDs or OLEDs have become though.

Roen · Jun 9, 2026

How would you suggest doing the thousands of beams you're going to need running at the same time with thousands of individual magnetic fields aiming each beam without them interfering with each other?

Why do you think 4 beams would be enough? The beam is not 4x too slow, it's orders of magnitude too slow, like I said. I don't know the exact number but 4 aint gonna do it.

Edit: let's simplify that to see if I'm talking nonsnse there. I used to have a pretty high end 1600x1200 max CRT that maxed out higher but got unsharp above 60Hz at that res. So let's assume 4 tubes, if you could somehow magically combine them without the magnetic fields interfering with each other, each tube capable of 1600x1200@60, if perfect performance scaling with 4 tubes vs 1 were achieved (which won't happen), 1600x1200=1920000. That x4 = 7680000 pixels. In 16:9 that would be 3,695 x 2079 at 60Hz, that's still not quite 4K @60Hz, and what OP asked for is high refresh rate at 4K.

Orders of magnitude was an exaggerration. Maybe 10 tubes would be enough for 4K@120Hz, with 10x the electronics driving them. It would have an insane power draw. I still don't see how it would be possible to combine them. You'd need strictly sectioned off magnetic fields. The trajectory of the beam, especially near the edges of each tube's target section is going to be affected by adjacent fields operating at the same time. You can probaby only fire one dot at a time even if you had 10 tubes. (Or they would've done it already to achieve higher refresh/resolution specs.)

elvn · Jun 9, 2026

I'm not lost in math, it's pretty clear to me, I'm just breaking it down.

For the record, if you read and understood what I was showing, I was arguing against CRT with that data.

A big takeaway being the best crt I know of, an aged phosphor fw900 crt , is around 80fpsHz max at anything even a step down from a modern 4k, 4+ resolution, with the crt at 2304 x 1440.

---------------------------------------------------------------------------------

80 fpsHz player vs 128fpsHz player on 128 tick server:

Highlights..

Fluctuating wait time means your input latency to the server is constantly changing by up to 7.8 ms from one millisecond to the next. This causes microscopic variations in when your shots register on the server.
A 128 FPS enemy moving around a corner updates the server every 7.81 ms. If they see you, their action registers instantly on the next server tick. Your client only updates every 12.5 ms, meaning you will see them step around the corner up to 4.7 ms later than a player with matching high-tier hardware.
The Sub-Tick / Interp Trap: Modern engines use interpolation to smooth out the gaps between your 12.5 ms frames. This creates a visual lie: your screen shows an enemy moving smoothly, but their actual hitbox on the server is already steps ahead because the server is calculating physics nearly twice as fast as your monitor can show them.

==========================

Idk what cost effective tech would make crts faster than that and still accurate/precise, if even possible, let alone at 4k, 4k+ and vs weights (re: "multi crt"). Not to mention newer energy restrictions in many countries making it a non-starter outright.

==========================

Roen said:
If you want the least latency in a modern monitor use an OLED, instead of an LCD and cap your fps to keep the GPU ~4% below max load (game engines don't always manage 100% uncapped, so I'm assuming 98% and subtract 2%). And use a mouse with a high polling rate. That's what's practical that you can do to affect that. Getting lost in latency math isn't going to help your latency and certainly won't bring back CRTs.

That's a good general rule but until you surpass 128 fpsHz on a 128tick server (on screen capable of showing you those scene updates, a 144hz+ screen) - you aren't reducing your gap to a 128 tick server enough for online games, at least if you want to not suffer a disadvantage vs. those that are.. So you'd not only, as you said, need a OLED capped beneath "a" frame rate, you'd need around 160fpsHz average in order to achieve 128tick as your 10% lows. (Even higher average if you want your .1% lows to remain 128 fpsHz vs 128 tick server, even though you can cap the top end).

For single player games, you'd also need high base to combat multiFramegen's added latency, and in general if you want more responsive single player games , less fov-movement blur, more motion definition/pathing articulation/smoothness/more animation frame states shown.

.

Lag Compensation & Visual Errors Matrix (Adjusted for Server Latency Floor) playing on a 128 tick server

Note: Even at 128 FPS, 140 FPS, or 160 FPS, your local client cannot bypass the laws of physics over the internet. You will still experience the base ~72ms temporal gap (caused by your network ping, server tick processing, and engine translation delays). Higher framerates only minimize your local hardware slice of that delay.

Client / Network Profile (native/post-DLSS)	Peeker's Advantage Vulnerability	"Super Bullets" Compression	Rubberbanding & Prediction Snapping	Local Client Simulation & Frame Prediction	Cons of the "Visual Lie" (Prediction Errors)
60 FPS Client (~100ms Total Window)	Severe. Attackers see you instantly. You remain blind until their data clears your massive 100ms pipeline.	High. Multiple fast server updates compress into a single slow monitor frame, causing instant-death illusions.	Violent Snaps. Massive temporal gaps cause heavy divergence between local client prediction and server truth.	Extrapolating in the Dark. Client must predict movement across ~16.67ms chunks between ticks. High likelihood of predicting completely wrong trajectories.	Phantom Targets. Enemies appear to continue running in a straight line for multiple frames when they actually stopped or changed direction, causing you to aim at a "ghost."
80 FPS Client (~87ms Total Window)	Moderate. Slightly reduced blind window, but still easily abused by high-framerate opponents.	Medium. Less severe packet grouping, but rapid-fire bursts can still merge into single-frame deaths.	Noticeable Skips. Jarring position corrections occur when your local engine syncs back up with the host server.	Chunky Prediction. Client interpolates and predicts in 12.5ms intervals. Visuals feel smoother than 60 FPS, but prediction errors are still highly visible.	Mismatched Hitboxes. The visual model of the enemy desyncs from their actual server hitbox during rapid strafing, making perfectly aimed shots miss entirely.
128 FPS Client (~72ms Total Window)	Baseline Online Delay. Still suffers from the core ~72ms network/server gap. Attackers still hold a standard online advantage.	Non-Existent. Frame loop matches server ticks, ensuring each distinct shot registers and displays independently.	Micro-Stutters. Minor, tight position adjustments due to high-frequency, real-time data streaming.	1:1 Server Sync. The client simulation loop perfectly matches the 128-tick server interval (~7.81ms). The engine rarely has to predict "blindly."	Standard Online Desync. Visual errors are minimized locally, but enemies will still micro-warp over the ~72ms network void during sudden, erratic direction changes.
140 FPS Client (~71ms Total Window)	Server-Capped. Still bound by the ~72ms network/server floor. Network alignment is identical to 128 FPS; local rendering shaves off an extra ~0.7ms of visual delay.	Zero Compression. Local loop outpaces the server tickrate, guaranteeing zero frame-level damage stacking.	Instantaneous. Near-invisible micro-shifts since your local prediction state stays tightly locked to real-time.	Micro-Prediction. Client outputs frames slightly faster (~7.14ms) than the server ticks. The engine predicts the sub-millisecond gap smoothly.	Persistent ~72ms Void. You render smoothly between server ticks, but because you are still playing ~72ms in the past, rapid jiggle-peeking still causes enemies to minutely "shiver" when server data catches up.
160 FPS Client (~69ms Total Window)	Local Edge Only. Still trapped behind the ~72ms network/server bottleneck. Network advantage equals 128 FPS; local rendering shaves off ~1.5ms of visual lag for faster muscle reactions.	Ultra-Fluid. Local frames exceed server updates, ensuring absolute visual separation of distinct damage events.	Flawless Recovery. Positional corrections are virtually seamless because your local state minimizes frame-time variance.	Oversampling Optimization. Client predicts and renders at a rapid ~6.25ms interval. Local camera panning and player movement feel incredibly fluid.	Fluid Disconnect. Your screen updates with extreme fluidity, but the underlying world data is still ~72ms old. Fast-moving items like thrown utility or ragdolls will look jittery when they snap back to the actual 72ms-delayed server timeline.
LAN / Local Player (<10ms Total Window)	Non-Existent. Zero network delay. Defending is perfectly fair, and holding angles is entirely viable.	Pure Reality. Sub-millisecond local server transit completely prevents network damage grouping or packet stacking.	Eliminated. The client and server remain in permanent lockstep, meaning the engine never needs to force a correction.	Absolute Sync. Prediction systems are entirely redundant. The client receives raw physics data from the local host instantly.	None. What you see is exactly what the server calculates. There is no "visual lie" because there are no missing network gaps to fill.

================================

Frame gen, which has been complained about in this thread, is more latency for sure, but it's way worse if your base is low ("trying to get blood from a stone"). Nvidia Reflex apparently only helps when there are bottlenecks.

-----------------------------------------------

With no bottlenecks, the Reflex ON column would be the save average latency as the No Reflex column. You can't use framegen without reflex being on afaik though, so it would always be on for that either way.

*In the real world, "No Reflex" and "Reflex ON" numbers only split when your system encounters a CPU bottleneck or a backed-up driver render queue
If you play a game without Reflex, the CPU often prepares frames much faster than the GPU can draw them. The driver creates a buffer queue to hold these extra frames.
No Reflex: The engine time might be 12.50 ms, but because 2 extra frames are trapped waiting in the driver queue, your actual average latency balloons to ~37.50 ms.
Reflex ON: Reflex completely deletes that queue. It tells the CPU to wait until the exact millisecond the GPU is ready, dropping your real latency back down to the pure 12.50 ms target.

--------------------------------------------------

Real-World Latency Chart (Input-Lag Sensitive Perspective)

Visual Output Rate	Underlying Engine Base	Avg Latency (No Reflex)	Avg Latency (Reflex ON)	Hand-to-Eye Responsiveness (Sensitive Player)
80 FPS (Native)	80 FPS	~38.00 ms	12.50 ms	Acceptable baseline (Borderline noticeable delay)
120 FPS (Native)	120 FPS	~26.00 ms	8.33 ms	Ultra-snappy (True raw input)
140 FPS (Native)	140 FPS	~21.00 ms	7.14 ms	Flawless and instantaneous
160 FPS (Native)	160 FPS	~18.00 ms	6.25 ms	Elite tier (Perfect direct response)

160 FPS (via x2 FG)	80 FPS Base	~48.50 ms	28.50 ms	Noticeable Lag (Heavy mouse, unplayable for FPS)
240 FPS (via x2 FG)	120 FPS Base	~35.66 ms	19.66 ms	Passable (Fluid visuals, but feels "soft" or filtered)
280 FPS (via x2 FG)	140 FPS Base	~29.78 ms	16.78 ms	Good (Minor input smoothing detected, but usable)
320 FPS (via x2 FG)	160 FPS Base	~25.00 ms	15.00 ms	Great (Very hard to distinguish from raw input)

320 FPS (via x4 FG)	80 FPS Base	~56.00 ms	32.00 ms	Severe Disconnect (Massive desync between eyes and hands)
480 FPS (via x4 FG)	120 FPS Base	~42.66 ms	22.66 ms	Deceptive Sluggishness (Looks like 480Hz, feels like 45 FPS)
560 FPS (via x4 FG)	140 FPS Base	~36.78 ms	19.78 ms	Passable (On the absolute edge of feeling "mushy")
640 FPS (via x4 FG)	160 FPS Base	~32.00 ms	18.00 ms	Good (Extreme visual fluidity masks the minor lag filter)

.

.

elvn · Jun 9, 2026

Roen said:
How would you suggest doing the thousands of beams you're going to need running at the same time with thousands of individual magnetic fields aiming each beam without them interfering with each other?

Why do you think 4 beams would be enough? The beam is not 4x too slow, it's orders of magnitude too slow, like I said. I don't know the exact number but 4 aint gonna do it.

Edit: let's simplify that to see if I'm talking nonsnse there. I used to have a pretty high end 1600x1200 max CRT that maxed out higher but got unsharp above 60Hz at that res. So let's assume 4 tubes, if you could somehow magically combine them without the magnetic fields interfering with each other, each tube capable of 1600x1200@60, if perfect performance scaling with 4 tubes vs 1 were achieved (which won't happen), 1600x1200=1920000. That x4 = 7680000 pixels. In 16:9 that would be 3,695 x 2079 at 60Hz, that's still not quite 4K @60Hz, and what OP asked for is high refresh rate at 4K.

Orders of magnitude was an exaggerration. Maybe 10 tubes would be enough for 4K@120Hz, with 10x the electronics driving them. It would have an insane power draw. I still don't see how it would be possible to combine them. You'd need strictly sectioned off magnetic fields. The trajectory of the beam, especially near the edges of each tube's target section is going to be affected by adjacent fields operating at the same time. You can probaby only fire one dot at a time even if you had 10 tubes. (Or they would've done it already to achieve higher refresh/resolution specs.)

.

pendragon1 · Jun 9, 2026

you should build one...

Roen · Jun 9, 2026

Still working out a few quirks in my free energy generation dark matter gyroscope. After that I'll get right on it.

sharknice · Jun 9, 2026

Roen said:
How would you suggest doing the thousands of beams you're going to need running at the same time with thousands of individual magnetic fields aiming each beam without them interfering with each other?

Why do you think 4 beams would be enough? The beam is not 4x too slow, it's orders of magnitude too slow, like I said. I don't know the exact number but 4 aint gonna do it.

Edit: let's simplify that to see if I'm talking nonsnse there. I used to have a pretty high end 1600x1200 max CRT that maxed out higher but got unsharp above 60Hz at that res. So let's assume 4 tubes, if you could somehow magically combine them without the magnetic fields interfering with each other, each tube capable of 1600x1200@60, if perfect performance scaling with 4 tubes vs 1 were achieved (which won't happen), 1600x1200=1920000. That x4 = 7680000 pixels. In 16:9 that would be 3,695 x 2079 at 60Hz, that's still not quite 4K @60Hz, and what OP asked for is high refresh rate at 4K.

Orders of magnitude was an exaggerration. Maybe 10 tubes would be enough for 4K@120Hz, with 10x the electronics driving them. It would have an insane power draw. I still don't see how it would be possible to combine them. You'd need strictly sectioned off magnetic fields. The trajectory of the beam, especially near the edges of each tube's target section is going to be affected by adjacent fields operating at the same time. You can probaby only fire one dot at a time even if you had 10 tubes. (Or they would've done it already to achieve higher refresh/resolution specs.)

I'm not saying it's easily feasible or anything, there is a ton of stuff they would have to solve.

But just imagine someone stacks square CRT TVs 9 tall and 16 wide in a huge multimonittor setup. If these each of these CRT TVs ran at 240x240 resolution at 500hz they be equivalent to a 4k 500hz display.

Now imagine instead of being stacked and next to each other you acombined them into one case with one piece of glass, all llined up perfectly to make one seamless screen.
.

Sycraft · Jun 9, 2026

sharknice said:
Now imagine instead of being stacked and next to each other you acombined them into one case with one piece of glass, all llined up perfectly to make one seamless screen.

And you thought alignment of CRTs was bad before!

That kind of thing is done with projectors and the issue is that you have to work real, real hard to keep the seams between the protectors invisible. You have to have them perfectly aligned, but spatially and geometrically, and you have to have the brightness and color matched. It also increases cost, of course.

Realistically if you are going to try that, you'd go the SED route instead where you have an array of electron emitters that just hit individual elements.

It also all comes down to why: Does doing any of this make a product that people want? I don't mean a few hard-core CRT lovers, I mean enough to make a commercially viable product.

sharknice · Jun 9, 2026

Sycraft said:
And you thought alignment of CRTs was bad before!

That kind of thing is done with projectors and the issue is that you have to work real, real hard to keep the seams between the protectors invisible. You have to have them perfectly aligned, but spatially and geometrically, and you have to have the brightness and color matched. It also increases cost, of course.

Realistically if you are going to try that, you'd go the SED route instead where you have an array of electron emitters that just hit individual elements.

It also all comes down to why: Does doing any of this make a product that people want? I don't mean a few hard-core CRT lovers, I mean enough to make a commercially viable product.

At 100 watts for each CRT it would be 14,400 watts of power

And if each CRT was 17 inches it would be about a 300" screen. Sounds like a fun DIY project. Get to work CRT freaks

toast0 · Jun 10, 2026

sharknice said:
At 100 watts for each CRT it would be 14,400 watts of power And if each CRT was 17 inches it would be about a 300" screen. Sounds like a fun DIY project. Get to work CRT freaks

Visions of Wet Seal and their wall of crts for no reason.

XoR_ · Jun 10, 2026

sharknice said:
Now imagine instead of being stacked and next to each other you acombined them into one case with one piece of glass, all llined up perfectly to make one seamless screen.

How would that be achieved exactly?

People have used multiple CRTs to make giant screens but you always had visible gaps between CRTs.
Any optical method as in using glass I don't think could ever be perfect and it certainly wouldn't make such display any lighter.

Much better idea is to use much smaller, simpler and more numerous light emitters like we are doing currently.

sharknice · Jun 10, 2026

XoR_ said:
How would that be achieved exactly?

People have used multiple CRTs to make giant screens but you always had visible gaps between CRTs.
Any optical method as in using glass I don't think could ever be perfect and it certainly wouldn't make such display any lighter.

Much better idea is to use much smaller, simpler and more numerous light emitters like we are doing currently.

It wouldn't be something you can just buy at the store. It would be like the micro LED walls where you bring in the pieces and assemble it on site. You could even choose how many you use for size and max resolution/frame rate.

Something like this except you there would be more substantial mounting hardware and power input, and you would get to spend 8000 hours on alignment.

View: https://youtu.be/qBd7_uxrq6c

This is doable DIY, you just gotta find 100 or so matching CRTs. C'mon CRT elitists. Make the ultimate display.

XoR_ · Jun 10, 2026

sharknice said:
This is doable DIY, you just gotta find 100 or so matching CRTs. C'mon CRT elitists. Make the ultimate display.

It is possible to slap some RGB LEDs or even R, G and B LEDs together and make display.
Anything where you need to assemble ready-made displays is pretty much no go because you inevitably hit and issue: what to do with bezels/gaps?

I simply don't know if there is any method to hide the gaps. If there is such glass shape which could do it it wouldn't be easy to make such glass and it would weight a ton and wouldn't allow you to easily scale up/down such display. That said I don't think it is physically doable at all. Maybe you could have it look ok from single sweet spot but that would look ridiculous from side. Also even if you could source CRTs for free such display would cost fortune.

Given you have giant RGB LED wall TVs with high higher gamut, much higher luminance, perfect HDR, etc. then your perfect display doesn't sound like the perfect display.
And if we talk motion clarity, refresh rate, etc. you don't need CRT for that.

Anyways, the idea is kinda sound but not in today's reality.
It might have made some sense in the past when we didn't have plasma but other than technical impossibility of it then the issue was lack of HD content... and the fact you could have just used CRT projector.

That said I need to give you one thing: you just made my dream new 32 inch 4K@240Hz CRT monitor sound like super duper trivial thing in comparison to your multi-CRT wall

sethk · Jun 12, 2026

This is a fun thread, and I think the ability to buy a new retro-style crt that targets enthusiasta like the smaller but very awesome Sony PVM line (the ones I have seen were about 13”) would be really cool and even seems like it would be a viable niche product if manufacturing tooling still exists somewhere. They make retro consoles and classic PC games look great, but more importantly they have that retro cool vibe and lifestyle viability- I can see them in many game rooms / home theaters or even on the shelf on streamers / creators backgrounds. Vinyl and tube amplifiers found a sustainable niche in the audiophile market and new designs come out everyday, why not CRTS?

Dreaming about the physics needed to make a 14KW 240hz 4K crt is fun too though

elvn · Jun 12, 2026

I think any modern iteration in a regular 15 inch or 17" crt format, and especially anything as large as a fw900 crt format or a xbr960 34" widescreen "720p"/1080i tv format, would not pass energy restrictions in major countries so they wouldn't bother making them for that reason alone. Plus, our AI overlords need all of that power, and more, so you can't have it.

shipping and returns vs that kind of weight and volume, and profit margins overall compared to LCD and OLED are probably not favorable, either.
.

elvn · Jun 12, 2026

Speaking of AI... google's genie (gemini) told me this:

A modern 27" 1440p CRT does not exist, as CRT production ceased in the early 2000s. However, if such a theoretical monitor were built to output HDR 600, it would be highly impractical—it would draw 250 to 500+ watts and require specialized industrial electrical circuits.
In contrast, a 45" OLED gaming monitor typically uses only 45 to 68 watts on average, and peaks around 100 to 130 watts during bright HDR scenes

Screen energy restrictions are strange since gpus can use so much power, but that's the way it is. Probably because there are way more people with tvs than high powered PC gaming rigs. (Hopefully they won't eventually stop making locally high performance gpus and restrict the big power ones to portal tech / gaming streaming services).

----- more from google ---

==================================

4K HDR 600 CRT

"A 4K HDR 600 CRT is fundamentally impossible due to physical limits, but theoretically would require 800 to 1,500+ watts.

Meanwhile, a 4K OLED gaming monitor typically draws a very manageable 35 to 55 watts on average, with maximum spikes around 130 to 190 watts under heavy use.

Theoretical 4K HDR 600 CRT: The Physics Bottleneck To achieve a crisp 4K resolution on a CRT, the internal "shadow mask" (the metal grid directing the electron beams) requires extremely microscopic holes.

The Problem: Shrinking the holes blocks out most of the electrons. To counteract this and still pump out a bright HDR 600 image, the electron guns must blast energy at catastrophic levels.
The Power Draw: Over 80% of that energy turns directly into heat rather than light. The monitor would draw between 800W and 1,500W+—comparable to running a space heater or microwave on your desk. The glass tube would get hot enough to crack, and it would likely trip a standard 15-amp household circuit breaker.

Modern 4K OLED Gaming Monitor: Efficient and Dense OLED power draw scales mostly with panel size and screen brightness rather than pixel count. Because the pixels generate their own light, moving from 1440p to 4K doesn't drastically change the display's base energy needs.

Typical Power Draw: High-end 4K OLED gaming monitors, such as the Alienware 32" 4K QD-OLED or the LG UltraGear 32" 4K OLED, consume only 35W to 55W during average SDR or HDR gaming.Peak Power Draw: When displaying a full-screen white image or an incredibly intense HDR flash, the panel can spike up to a maximum rating of 130W to 190W. (Note: Manufacturers often package these with 200W+ power bricks to account for built-in USB ports that can charge laptops via USB-C) "

=====================================

"
The Engineering Reality Check : 250nit to 350nit 4k CRT

We can actually estimate this using real-world high-end production history. When Hollywood and broadcast studios needed 4K reference monitors at exactly these brightness levels (around 100 to 300 nits), they completely abandoned CRT technology. Instead, they built dual-layer LCDs and professional OLEDs like the Sony BVM-X300 and BVM-HX310. Even with modern flat-panel components, those professional 4K mastery monitors draw between 280W and 450W just to process that many pixels with perfect color accuracy.

If you tried to achieve this back inside a glass vacuum tube, the power behaves like this:

The Raster & Focusing Power: Maintaining a beam focus sharp enough to resolve 8.3 million distinct pixels (4K) requires massive electromagnetic force. The deflection yokes and high-voltage anodes would require roughly 150W to 200W of baseline power just to scan the screen, even if the image displayed was completely pitch black.
The Brightness Power: Pushing 250 to 350 nits through a microscopic 4K shadow mask still loses a massive amount of energy to electron blockage. Driving the electron guns hard enough to fight that blockage and illuminate the phosphors would add another 150W to 250W of power draw during bright, full-screen scenes.
The Dynamic Power Fluctuation: Like a modern OLED, the CRT's power draw would fluctuate wildly. A dark movie scene might only pull 200W, while a bright webpage or white desktop background would immediately cause the monitor to choke, spiking up to 450W and throwing off a significant amount of ambient heat

"

Darunion · Jun 12, 2026

sethk said:
This is a fun thread, and I think the ability to buy a new retro-style crt that targets enthusiasta like the smaller but very awesome Sony PVM line (the ones I have seen were about 13”) would be really cool and even seems like it would be a viable niche product if manufacturing tooling still exists somewhere. They make retro consoles and classic PC games look great, but more importantly they have that retro cool vibe and lifestyle viability- I can see them in many game rooms / home theaters or even on the shelf on streamers / creators backgrounds. Vinyl and tube amplifiers found a sustainable niche in the audiophile market and new designs come out everyday, why not CRTS?

Dreaming about the physics needed to make a 14KW 240hz 4K crt is fun too though

CRTs are more costly to manufacture than turntables. So to price accordingly would be expensive and because you wont move high volumes you need to price again even more so. I do think size and weight will always hold CRT back from being desirable on any scale that makes financial sense.

Nostalgia has to make sense too. I don't think VCR's are being produced anymore either. I would guess because also the experience isn't enough to make the juice worth the squeeze.

Would a modern CRT make any sense?

Cat Can't Scratch It

Supreme [H]ardness

2[H]4U

[H]F Junkie

Supreme [H]ardness

2[H]4U

[H]F Junkie

Supreme [H]ardness

2[H]4U

Supreme [H]ardness

2[H]4U

Supreme [H]ardness

Supreme [H]ardness

Supreme [H]ardness

2[H]4U

Weaksauce

2[H]4U

Weaksauce

[H]F Junkie

Supreme [H]ardness

Weaksauce

Supreme [H]ardness

Supreme [H]ardness

Cat Can't Scratch It

Weaksauce

Supreme [H]ardness

Supreme [H]ardness

Supreme [H]ardness

Supreme [H]ardness

2[H]4U

Supreme [H]ardness

2[H]4U

2[H]4U

Supreme [H]ardness

Supreme [H]ardness

[H]F Junkie