11 ms·

I fiddle in this area as a hobby project. One thing I never understand when I read announcements like this is why the graphics performance affects the throughp

• tomc1985 8y ago
  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.
  • crawshaw 8y ago
    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.
  • altfredd 8y ago
    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.
    • jayd16 8y ago
      >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.
    • evmar 8y ago
      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).
• sedatk 8y ago
  The IRC client XiRCON did that back in 90’s. Regardless how slow your machine is you always got the output instantly, albeit with less FPS.
• andrewstuart2 8y ago
  > Like in a video game, the world moves at the same rate regardless of the frame rate If only this were true. There are plenty of games where the frame rate is capped at 60hz because the physics engine is coupled to it. If you force a framerate increase via .ini tweaks or something, you get really weird physics. I think Skyrim had this problem. Also, there are examples of where changing the network tick rate [1] can affect the physics engines. [1] https://www.youtube.com/watch?v=sB5u96Vgyks https://www.youtube.com/watch?v=sB5u96Vgyks
  • saagarjha 8y ago
    What happens if your computer can't support a 60 Hz frame rate?
    • deleted 8y ago
      [deleted]
    • LeoNatan25 8y ago
      The games slow down. Until recently, most Japanese games were tightly tied to 30hz or 60hz logic, and would speed up or slow down if forced (willfully or not) to run at different frequency. This is not strictly a Japanese games phenomenon, but I've seen it mostly in PC ports of Japanese developed games for consoles. To me, that's bad software design. 40 years ago, developers used to sync their logic to the refresh cycles of the target machine's display. That's amazing, but also something that should not happen in 2018 (or 2010 or 1998).
      • peterburkimsher 8y ago
        Isn't that the reason for the Turbo button? For the younglings: it was a physical button to underclock the CPU on old PCs. https://en.m.wikipedia.org/wiki/Turbo_button https://en.m.wikipedia.org/wiki/Turbo_button
        • LeoNatan25 8y ago
          Yes, but the turbo button is and should remain a relic of the past, rather than a cornerstone of modern gaming design.
• deleted 8y ago
  [deleted]
• ebbv 8y ago
  Nobody bothers to decouple them because usually rendering a terminal is trivial and the output rate isn’t as fast for most use cases. But it sounds like if you’ve done it before it might be a cool thing to contribute to your preferred open source terminal program (if you want to.)
  • ComputerGuru 8y ago
    That’s simply not true. A lot of terminals can’t output even ‘ls’ fast enough once colored output is enabled.
  • hk__2 8y ago
    > But it sounds like if you’ve done it before it might be a cool thing to contribute to your preferred open source terminal program (if you want to.) It’s not trivial to implement it in an existing codebase. Quoting from ITerm2’s Subpixel Antialiasing document: > iTerm2’s design burdens the main thread with handling input from the TTY. A better design would perform only drawing and other UI activity on the main thread, but it’s too hard to change as there are thousands of implicit assumptions baked in to the code.
• gnachman 8y ago
  It's a funny feeling opening hacker news and seeing your project at the top :) In iTerm2's case it's because of bad decisions about a decade ago. The data model is read & written on the main thread. The main thread is solely responsible for drawing operations if you use the standard drawRect: interface on NSView. That means that a slow draw blocks it from processing more data. Other work, like reading from the socket and parsing bytes into tokens was offloaded onto other threads years ago. Unwinding all the assumptions about single-threadedness is nearly impossible. The only way to reduce the main thread's workload is to use a GPU renderer because building the data structures the GPU needs can be done off the main thread after a quick copy of the necessary state.
  • chris_st 8y ago
    Hey, happy user here -- thanks for doing iTerm2!
  • xtreak29 8y ago
    Thanks much for iTerm 2 :)
  • natvert 8y ago
    Yes, thank you! Perhaps this has been asked before, but is there any hope of an Ubuntu port?
    • gnachman 8y ago
      Only if openstep catches up with Apple, or I retire. I wouldn’t hold my breath.
      • natvert 8y ago
        Haha, ok. Thank you again for all your hard work! Iterm2 is 90% the reason I pay a premium for a Mac. I would gladly skip paying the apple tax and put the funds toward iterm2 on other platforms if it ever becomes available :)
    • fooker 8y ago
• jayd16 8y ago
  Hmm well my guess is that for a lot of terminal apps they're expecting to draw directly to the screen without ever dropping a frame. You could add a buffer but if you can't drop frames that will only smooth out vsync wait.
• h2j24 8y ago
  Is that truly the case for games? I thought game logic was usually programmed against a clock, so that the game logic isn't dependent on running at some pre-determined frequency. However, is it typically the case that the number of ticks per second is independent of the render time?
  • AgentME 8y ago
    Some games do it differently, but evmar's advice matches recommendations that I've seen for game engines[0]. [0] https://gafferongames.com/post/fix_your_timestep/ https://gafferongames.com/post/fix_your_timestep/