Hacker News Reader

Comment by tomc1985 | Hacker News Reader

tomc1985

Unless the programmer specifically decouples graphics from the rest of the program, anything that renders to the screen will have to wait for that command to finish drawing. It will effectively govern the throughput of any program that both prints lots of text to screen and is not appropriately multithreaded.

View on HN

Evan knows that. His question is why isn't it normal for the graphics to be explicitly decoupled in terminal emulators that care about draw performance.

Wrong. Splitting logic into separate threads is not necessary. In order to make the engine independent from FPS, you have to decide, how to handle excess/missing output. You can buffer, transform, average or simply drop excess frames. Missing frames can be worked around by repeating previous frames or reducing effective resolution (often done with a bit of blur — hi, Nvidia!). In either case there are limits to what can be achieved with those workarounds — eventually you'd have to throttle the fastest producer (renderer, physics engine or player input). All of that can be done just fine without threads — using asynchronous programming (incidentally, this is why many advanced rendering APIs are asynchronous).

Most games can simply "drop frames", when renderer isn't up to speed with engine. The result is minor loss of visual fidelity, which usually isn't too bad, unless FPS are horribly low. Things are more tricky for terminals, because 1) they need to maintain scrollback history 2) their output is more blocky, so "dropping frames" leads to horribly-looking ASCII animations.

There are some terminals, that do start dropping output, when rendered can't keep up. Others (for example, xterm) do refuse to do that by default, because they assume, that underlying program may do better job at handling low framerate, than general-purpose terminal emulator.

Either way, if you want to achieve fluid, visually pleasing rendering, you renderer should be as fast as possible.

>Splitting logic into separate threads is not necessary.

Unless you're already using Vulkan/Metal your render thread will most certainly be lockstep with the GPU and that will block your CPU throughput.

You haven't described CPU/GPU independence at all. You're just talking about sacrificing the FPS for CPU perf.

I don't know why this one was downvoted. It is exactly right. You don't need threads, you just need your function that parses input to not try to write everything it sees to the screen (drop frames).

Reply on news.ycombinator.com