The section about "racing the beam" is interesting. > But that means that rather than doing rendering work once every 16.6 ms, you have to do it once per bloc

The section about "racing the beam" is interesting. > But that means that rather than doing rendering work once every 16.6 ms, you have to do it once per block. Suppose the screen is split into 16 blocks; then one block has to be rendered per millisecond. While the same number of pixels still need to be rendered overall, some data structure – possibly the whole scene database, or maybe just a display list, if results are good enough without stepping the internal simulation to the time of each block – still has to be traversed once per block to determine what to draw. You could do a pretty simple hack though, that might be good enough: Render the frame onto a buffer, as usual, but instead of displaying it, re-render it using beam-racing with the proper rotation around the viewer to counter the latency of the rendering and transfer time. This would be a bit like how Google Streetview interpolates the panoramas when you move, but very much simplified, since you only correct for rotation. Edit: Fixed the "ream-racing" typo.