4 ms·

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. Tha

• katastic 9y ago
  > 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.
  • bla2 9y ago
    People demand 60fps, so systems prioritize throughput over latency. See all the layer-based systems like coreanimation.
    • mrob 9y ago
      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.
      • bla2 9y ago
        Sure, but they pushed way fewer pixels with way fewer colors.
    • cwzwarich 9y ago
      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.
      • bla2 9y ago
        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.
      • raphlinus 9y ago
        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.
• black_puppydog 9y ago
  while that's true, for the use case "terminal" it doesn't matter, since the information transmitted from CPU to brain doesn't change.
  • terminalcommand 9y ago
    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.
    • koide 9y ago
      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.
      • yjftsjthsd-h 9y ago
        Or a sign that you need more scripts/aliases
    • floatboth 9y ago
      Try mosh, it displays keystrokes locally before the response from the server comes in.
• cwzwarich 9y ago
  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.