3 ms·

- 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 resp

- 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.
  - Fnoord 2y ago
    Because _my_ computer has no battery. There is a plethora of computers out there with batteries who can run Linux, Windows, and macOS. These computers can, on paper, run Alacritty. Cherry on top is me being a former user of a MBP 2010 who'd crash when using discrete GPU (it was _the_ reason Apple went with AMD later on). And some apps insisted on using it, even when I disabled it. I like Rust applications but I don't like this response. The dev sounds worn out; whereas the dev of Ghostty seems to be a pleasure to deal with.
ayushgun 2y ago
> - Ghostty sets non-focused rendering threads as QoS background to go onto E-cores Assuming you're referring to Apple Silicon chips, how does Ghostty explicitly pin a thread to an E-core? IIRC there isn't an explicit way to do it, but I may be misremembering.
- ec109685 2y ago
  The QoS influences the core threads are placed on https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon#:~:text=Accurately%20assigning%20QoS%20classes%20to,and%20QoS%20classes%2C%20see%20Dispatch https://developer.apple.com/documentation/apple-silicon/tuni....
- broknbottle 2y ago
  You can tell something to run on e-core just not p-cores
Filligree 2y ago
> - Ghostty slows down rendering significantly if the window is obscured completely (not visible) About this. For whatever reason, I often end up with foreground windows (e.g. Chrome) covering the background window entirely, except for a sliver a few pixels wide. Would Ghostty handle this case? I don't believe there's any point in full-speed rendering if less than a single line of text is shown, but the window isn't technically obscured completely.
- mitchellh 2y ago
  We rely on the OS to tell us when we're obscured, and macOS will only tell us if the window is fully obscured (1 pixel showing is not obscured).
tuananh 2y ago
can i configure it to run on dedicated? im on desktop, power consumption is not an issue.
- stouset 2y ago
  I struggle to understand why any of the above approaches would cause any impact worth maintaining a configuration flag over.

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.
- Fnoord 2y ago
  Because _my_ computer has no battery. There is a plethora of computers out there with batteries who can run Linux, Windows, and macOS. These computers can, on paper, run Alacritty. Cherry on top is me being a former user of a MBP 2010 who'd crash when using discrete GPU (it was _the_ reason Apple went with AMD later on). And some apps insisted on using it, even when I disabled it. I like Rust applications but I don't like this response. The dev sounds worn out; whereas the dev of Ghostty seems to be a pleasure to deal with.

ayushgun 2y ago

> - Ghostty sets non-focused rendering threads as QoS background to go onto E-cores Assuming you're referring to Apple Silicon chips, how does Ghostty explicitly pin a thread to an E-core? IIRC there isn't an explicit way to do it, but I may be misremembering.

ec109685 2y ago
The QoS influences the core threads are placed on https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon#:~:text=Accurately%20assigning%20QoS%20classes%20to,and%20QoS%20classes%2C%20see%20Dispatch https://developer.apple.com/documentation/apple-silicon/tuni....
broknbottle 2y ago
You can tell something to run on e-core just not p-cores

Filligree 2y ago

> - Ghostty slows down rendering significantly if the window is obscured completely (not visible) About this. For whatever reason, I often end up with foreground windows (e.g. Chrome) covering the background window entirely, except for a sliver a few pixels wide. Would Ghostty handle this case? I don't believe there's any point in full-speed rendering if less than a single line of text is shown, but the window isn't technically obscured completely.

mitchellh 2y ago
We rely on the OS to tell us when we're obscured, and macOS will only tell us if the window is fully obscured (1 pixel showing is not obscured).

tuananh 2y ago

can i configure it to run on dedicated? im on desktop, power consumption is not an issue.

stouset 2y ago
I struggle to understand why any of the above approaches would cause any impact worth maintaining a configuration flag over.