4 ms·

Great article. The brute force solution to this problem is switching to high refresh rate monitors, but if you want to beat Apple II latency by brute force with

Great article. The brute force solution to this problem is switching to high refresh rate monitors, but if you want to beat Apple II latency by brute force without fixing the underlying issues in modern software then 120 Hz probably isn't enough. You need crazy high refresh rates like 240 or 360 Hz. I do enjoy high refresh rates, but they are not great for power consumption and limit the resolution you can support.

Daishiman 6y ago
A high refresh monitor isn't going to do much if your synchronization primitives and scheduling capabilities aren't up to the task. A millisecond of latency in the compositor is still a millisecond no matter what output refresh rate you have.
- wffurr 6y ago
  Latency is almost always in frames, the renderer is one frame behind the compositor which is one frame behind scanout. If each steps takes 4 msec (240 Hz) instead of 16.7 msec (60 Hz), and you're the same number of steps behind, the latency is reduced by (16.7 - 4) * nsteps, or 50 msec - 12 msec = 38 msec. Now that's assuming your system can actually keep up and produce frames and composite that fast, which is where the "brute force" comes into play.
  - maximilianroos 6y ago
    Why is that delay coupled to the monitor that's plugged into the computer? Could we ask the computer to produce graphics at 240Hz and then take every 4th frame? Then we have "average" delay in ms rather than frames. (Asking as someone who doesn't know this area well)
    - modeless 6y ago
      You could do that in theory but it would be wasteful to render frames that are never displayed. If you can modify the software, better to modify it as the article advocates for, to strip latency without the waste.
    - gpm 6y ago
      > Could we ask the computer to produce graphics at 240Hz and then take every 4th frame? More than could, some games let you do this explicitly.
    - zokier 6y ago
      You sould effectively get the same result by delaying compositing by 3/4th of a frame
      - gpm 6y ago
        Only if you know how long it will take to render a frame. If you render "as fast as possible (to a max of xyz hz), you get better worst case performance than if you delay compositing. A render time of 2 physical frames results in only 1 missed frame instead of a render time of 1.26 physical frames resulting in 2 missed frames. Of course nothing is simple in the real world, the flip side is rendering the extra frames creates waste heat that slows down modern processors with insufficient cooling.
badsectoracula 6y ago
Indeed it doesn't. I have a 120Hz CRT on one of my old PCs where moving/resizing windows, etc feels butter smooth so i decided to buy a 165Hz monitor for my main PC to try and capture the same experience. All i ended capturing was something approximating the experience i had back when Windows allowed me to disable the compositor which wasn't vsynced. It still doesn't feel as smooth, just smoother. Nowhere near the smoothness of my CRT though.
sprash 6y ago
And the brute force solution is the better solution this case. 240 or 360 Hz are not that "crazy" in the grand scheme of things considering 8k Displays will be the norm soon and the additional complexity in software and GPU hardware proposed in this article will completely useless and wasted effort once we are there.

Daishiman 6y ago

A high refresh monitor isn't going to do much if your synchronization primitives and scheduling capabilities aren't up to the task. A millisecond of latency in the compositor is still a millisecond no matter what output refresh rate you have.

wffurr 6y ago
Latency is almost always in frames, the renderer is one frame behind the compositor which is one frame behind scanout. If each steps takes 4 msec (240 Hz) instead of 16.7 msec (60 Hz), and you're the same number of steps behind, the latency is reduced by (16.7 - 4) * nsteps, or 50 msec - 12 msec = 38 msec. Now that's assuming your system can actually keep up and produce frames and composite that fast, which is where the "brute force" comes into play.
- maximilianroos 6y ago
  Why is that delay coupled to the monitor that's plugged into the computer? Could we ask the computer to produce graphics at 240Hz and then take every 4th frame? Then we have "average" delay in ms rather than frames. (Asking as someone who doesn't know this area well)
  - modeless 6y ago
    You could do that in theory but it would be wasteful to render frames that are never displayed. If you can modify the software, better to modify it as the article advocates for, to strip latency without the waste.
  - gpm 6y ago
    > Could we ask the computer to produce graphics at 240Hz and then take every 4th frame? More than could, some games let you do this explicitly.
  - zokier 6y ago
    You sould effectively get the same result by delaying compositing by 3/4th of a frame
    - gpm 6y ago
      Only if you know how long it will take to render a frame. If you render "as fast as possible (to a max of xyz hz), you get better worst case performance than if you delay compositing. A render time of 2 physical frames results in only 1 missed frame instead of a render time of 1.26 physical frames resulting in 2 missed frames. Of course nothing is simple in the real world, the flip side is rendering the extra frames creates waste heat that slows down modern processors with insufficient cooling.

badsectoracula 6y ago

Indeed it doesn't. I have a 120Hz CRT on one of my old PCs where moving/resizing windows, etc feels butter smooth so i decided to buy a 165Hz monitor for my main PC to try and capture the same experience. All i ended capturing was something approximating the experience i had back when Windows allowed me to disable the compositor which wasn't vsynced. It still doesn't feel as smooth, just smoother. Nowhere near the smoothness of my CRT though.

sprash 6y ago

And the brute force solution is the better solution this case. 240 or 360 Hz are not that "crazy" in the grand scheme of things considering 8k Displays will be the norm soon and the additional complexity in software and GPU hardware proposed in this article will completely useless and wasted effort once we are there.