4 ms·

Just make sure not to get caught in the pitfall that is maximum render speed, which can lead to missing out on efficiency during slow and partial rendering. Mi

Just make sure not to get caught in the pitfall that is maximum render speed, which can lead to missing out on efficiency during slow and partial rendering. Missing damage tracking, always painting everything (even when the window is a full 4k monitor), etc. kills performance and input latency when dealing with realistic redraw workloads like text editing, blinking cursors and progress bars. Much too often to terminals worry only about the performance of `cat /dev/urandom`...

_7tgr 2y ago
Right, input latency is what matters for me. I'm not seeing whether they've measured that in the docs/on Github.
- CalebJohn 2y ago
  He mentions input latency[1] as one of 4 aspects of being fast that were considered during development. I’m not aware of how that was tested, but would trust that it outperforms Iterm2 in that regard. [1] https://www.youtube.com/watch?v=cPaGkEesw20&t=3015s https://www.youtube.com/watch?v=cPaGkEesw20&t=3015s
imron 2y ago
> kills performance And battery. I gave up on alacritty because it was always using the dedicated graphics card of my MacBook and there was no reasonably way to use the integrated graphics card because it was “low performance”.
- mitchellh 2y ago
  - Ghostty does vsync by default and supports variable refresh rates (DisplayLink). If you're on battery and macOS wants to slow Ghostty down, it can and we respect it. - Ghostty picks your integrated GPU over dedicated/external - Ghostty sets non-focused rendering threads as QoS background to go onto E-cores - Ghostty slows down rendering significantly if the window is obscured completely (not visible) No idea if Alacritty does this, I'm not commenting about that. They might! I'm just talking from the Ghostty side.
  - imron 2y ago
    That's a great approach. Not sure on the current state of Alacritty, but a few years back the suggested solution for users interested in battery performance was to switch to a different terminal emulator: https://github.com/alacritty/alacritty/issues/3473#issuecomment-602140675 https://github.com/alacritty/alacritty/issues/3473#issuecomm...
    - indemnity 2y ago
      This is the Alacritty answer to a lot of queries. I took the advice, eventually.
      - imron 2y ago
        Yep. That comment was when I stopped using Alacritty.
    - diggan 2y ago
      I, a person who don't care about battery performance one iota (because my computer has no battery), love this answer and approach. Not every software is for everyone, and authors drawing a line in the sand like that works out better for everyone in the long-term, instead of software that kind of works OK for everything.
      - mitchellh 2y ago
        In some cases yes. In this case, in my opinion it can be strictly wrong. The GPU requirements of a terminal are _minuscule_ even under heavy load. We're not building AAA games here, we're building a thing that draws a text grid. There is no integrated GPU on the planet that wouldn't be able to keep a terminal going at an associated monitor's refresh rate. From a technical standpoint, there is zero downside whatsoever to always using the integrated GPU (the stance Ghostty takes) and plenty of upside.
      - imron 2y ago
        More than happy for software authors to draw a line in the sand - I’ve done that myself too. I just find myself on the other side of the line for Alacritty.
epcoa 2y ago
> Missing damage tracking, always painting everything (even when the window is a full 4k monitor), Out of curiosity, what GPU accelerated terminal does this.
- cztomsik 2y ago
  +1, no idea. But maybe to add a little bit of context, "damage tracking" means for example, that if there is any ongoing animation (like a spinner), then only a small part of the screen will be re-rendered (with proper vertex-time scissors, so only relevant pixels will be computed). I am not sure if it makes sense in the context of a terminal emulator, but it's certainly a big issue for any non-toy GUI toolkits. GPUs are incredibly fast parallel computers, so you will likely not observe any perf difference (unless you need order-dependent transparency which you don't), but it might improve your battery life significantly.
  - arghwhat 2y ago
    No, damage tracking is important as it about reporting that you only updated that spinner, which means that your display server also knows to only redraw and repaint that area, and in turn that your GPU knows during scanout that only that area changed. Without, even if you only redrew your spinner, your display server ends up having to redraw what might be a full screen 4k window, as well as every intersecting window above and below until an opaque surfaces are hit to stop blending.
    - cztomsik 2y ago
      That's what I meant to say. There are 2 parts, and both need to work correctly, otherwise you're wasting power.
    - epcoa 2y ago
      Well it sounds like ghostty is like all the other major GPU terminal emulators (unless you know of a counterexample) and does full redraw, though it appears to have some optimizations about how often that occurs. The power issue might be true in some cases, but even as foot’s own benchmarks against alacritty demonstrate, it’s hyperbolic to say it “kills performance”.

_7tgr 2y ago

Right, input latency is what matters for me. I'm not seeing whether they've measured that in the docs/on Github.

CalebJohn 2y ago
He mentions input latency[1] as one of 4 aspects of being fast that were considered during development. I’m not aware of how that was tested, but would trust that it outperforms Iterm2 in that regard. [1] https://www.youtube.com/watch?v=cPaGkEesw20&t=3015s https://www.youtube.com/watch?v=cPaGkEesw20&t=3015s

imron 2y ago

> kills performance And battery. I gave up on alacritty because it was always using the dedicated graphics card of my MacBook and there was no reasonably way to use the integrated graphics card because it was “low performance”.

mitchellh 2y ago
- Ghostty does vsync by default and supports variable refresh rates (DisplayLink). If you're on battery and macOS wants to slow Ghostty down, it can and we respect it. - Ghostty picks your integrated GPU over dedicated/external - Ghostty sets non-focused rendering threads as QoS background to go onto E-cores - Ghostty slows down rendering significantly if the window is obscured completely (not visible) No idea if Alacritty does this, I'm not commenting about that. They might! I'm just talking from the Ghostty side.
- imron 2y ago
  That's a great approach. Not sure on the current state of Alacritty, but a few years back the suggested solution for users interested in battery performance was to switch to a different terminal emulator: https://github.com/alacritty/alacritty/issues/3473#issuecomment-602140675 https://github.com/alacritty/alacritty/issues/3473#issuecomm...
  - indemnity 2y ago
    This is the Alacritty answer to a lot of queries. I took the advice, eventually.
    - imron 2y ago
      Yep. That comment was when I stopped using Alacritty.
  - diggan 2y ago
    I, a person who don't care about battery performance one iota (because my computer has no battery), love this answer and approach. Not every software is for everyone, and authors drawing a line in the sand like that works out better for everyone in the long-term, instead of software that kind of works OK for everything.
    - mitchellh 2y ago
      In some cases yes. In this case, in my opinion it can be strictly wrong. The GPU requirements of a terminal are _minuscule_ even under heavy load. We're not building AAA games here, we're building a thing that draws a text grid. There is no integrated GPU on the planet that wouldn't be able to keep a terminal going at an associated monitor's refresh rate. From a technical standpoint, there is zero downside whatsoever to always using the integrated GPU (the stance Ghostty takes) and plenty of upside.
    - imron 2y ago
      More than happy for software authors to draw a line in the sand - I’ve done that myself too. I just find myself on the other side of the line for Alacritty.

epcoa 2y ago

> Missing damage tracking, always painting everything (even when the window is a full 4k monitor), Out of curiosity, what GPU accelerated terminal does this.

cztomsik 2y ago
+1, no idea. But maybe to add a little bit of context, "damage tracking" means for example, that if there is any ongoing animation (like a spinner), then only a small part of the screen will be re-rendered (with proper vertex-time scissors, so only relevant pixels will be computed). I am not sure if it makes sense in the context of a terminal emulator, but it's certainly a big issue for any non-toy GUI toolkits. GPUs are incredibly fast parallel computers, so you will likely not observe any perf difference (unless you need order-dependent transparency which you don't), but it might improve your battery life significantly.
- arghwhat 2y ago
  No, damage tracking is important as it about reporting that you only updated that spinner, which means that your display server also knows to only redraw and repaint that area, and in turn that your GPU knows during scanout that only that area changed. Without, even if you only redrew your spinner, your display server ends up having to redraw what might be a full screen 4k window, as well as every intersecting window above and below until an opaque surfaces are hit to stop blending.
  - cztomsik 2y ago
    That's what I meant to say. There are 2 parts, and both need to work correctly, otherwise you're wasting power.
  - epcoa 2y ago
    Well it sounds like ghostty is like all the other major GPU terminal emulators (unless you know of a counterexample) and does full redraw, though it appears to have some optimizations about how often that occurs. The power issue might be true in some cases, but even as foot’s own benchmarks against alacritty demonstrate, it’s hyperbolic to say it “kills performance”.