Hacker News Reader

Comment by bla2 | Hacker News Reader

One thing the article doesn't mention is that modern devices push two orders of magnitude more pixels with one order of magnitude more color bits per pixel. That requires much higher throughput, which causes much of the added latency on the display end.

View on HN

That doesn't really have much to do with it. The big difference is that now we are compositing 2D UI using GPUs, which require double buffering if you want to avoid tearing.

Older 2D accelerators had hardware support for beam-avoiding blits that allowed for single-buffered compositing. You could still see unsynchronized blits between distinct buffers, though. We could easily build 2D accelerators that work like this today, and they would use less power than GPUs.

while that's true, for the use case "terminal" it doesn't matter, since the information transmitted from CPU to brain doesn't change.

Well, ssh sometimes certainly feels sluggish to me. If you have your aliases configured and are typing at a high speed, you should be basically limited by your fingers.

Terminal use at this level of focus, is inseperable from thinking. You do not think to compose a command nor contemplate to move your fingers to type and execute, it just happens.

Therefore I think latency is also severely important at the terminal level.

This is not an apology for high latency, although, on the other hand, typing at the speed of thought is the main cause for rm -rf / and other similar mishaps.

Or a sign that you need more scripts/aliases

Try mosh, it displays keystrokes locally before the response from the server comes in.

> That requires much higher throughput, which causes much of the added latency on the display end.

That's not all the reason. More pixels pushed would only increase latency if the CPU/memory/etc wasn't faster than the older computers.

People demand 60fps, so systems prioritize throughput over latency. See all the layer-based systems like coreanimation.

Most old console and arcade games ran at 60fps without any abstraction layers. 60fps is the bare minimum, not a special requirement. You can already buy 240Hz monitors.

Sure, but they pushed way fewer pixels with way fewer colors.

The main benefit of layer-based systems is latency, not throughput. Prerendered layer contents give you lower latency (and more consistent latency, which is usually more important perceptually) when scrolling, because you only have to adjust the positions of layers.

Yeah, this is actually a super-complicated tradeoff. Whether layers are a win or not is largely a function of how much of the screen can be cached in the layer and how much needs to be re-rendered, so in the scrolling use case a function of how fast you're scrolling, and of course how long it takes to re-render the content. Once your scroll speed exceeds the rate at which new content can be rendered, the experience degrades.

My conclusion is that if being able to re-render the content consistently in under one frame time is feasible, it's a win over layers. Fortunately, this is possible if you're willing to write fast code to render on the GPU.

There's a lot more complexity to this based on whether compositor latency is optional. Generally if you go fullscreen you can bypass the compositor. This is feasible for games but much less so for terminals and editors. I think that in some cases on Windows a swapchain can be promoted to a hardware overlay, and there you also get the opportunity to save one frame of latency. I think we'll see more of this in the future.

I'll write about this in more detail (with measurements) soon.

Fast scrolling of prerendered layers is what I mean with throughput. You can move layers around quickly as long as their contents don't need rerendering.

Reply on news.ycombinator.com