Gaming

Hm... good point... but... let's see, assuming full parallel processing:

• [...]
• Frame -2 ready
• Frame -1 ready
  • Show frame -2
  • Start interpolating -2|-1 (should take less than 16ms)
  • Start rendering Frame 0 (will take 33ms)
  • User input 0 (will be received in 20ms if wired)
• Wait 16ms
  • Frame -2|-1 ready
• Show Frame -2|-1
• Wait 4ms
  • Process User input 0 (max 12ms to get into next frame)
  • User input 1 (will be received in 20ms if wired)
• Wait 12ms
• Frame 0 ready
  • Show Frame -1
  • Start interpolating -1|0 (should take less than 16ms)
  • Start rendering Frame 1 {includes User input 0} (will take 33ms)
• Wait 8ms
  • Process User input 1 (...won't make it into a frame before User input 2 is received)
  • User input 2 (will be received in 20ms if wired)
• Wait 8ms
  • Frame -1|0 ready
• Show Frame -1|0
• Wait 12ms
  • Process User Input 1+2 (...will it take less than 4ms?)
• Wait 4ms
• Frame 1 ready {includes user input 0}
  • Show Frame 0
  • Start interpolating 0|1 (should take less than 16ms)
  • Start rendering Frame 2 {includes user input 1+2... maybe} (will take 33ms)
• Wait 16ms
  • Frame 0|1 ready {includes partial user input 0}
• Show Frame 0|1 {includes partial user input 0}
• Wait 16ms
• Frame 2 ready {...hopefully includes user input 1+2}
  • Show Frame 1 {includes user input 0}
• [...]

So...

• From user input to partial display: 66ms
• From user input to full display: 83ms
• Some user inputs will be bundled up
• Some user inputs will take some extra 33ms to get displayed

Effectively, an input-to-render equivalent of between a blurry 15fps, and an abysmal 8.6fps.

Could be interesting to run a simulation and see how many user inputs get bundled or "lost", and what the maximum latency would be.

Still, at a fixed 30fps, the latency would be:

• 20ms best case
• 53ms worst case (missed frame)