Hacker News Reader

Comment by mitchellh | Hacker News Reader

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

View on HN

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#issuecomm...

This is the Alacritty answer to a lot of queries. I took the advice, eventually.

Yep. That comment was when I stopped using Alacritty.

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.

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.

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.

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.

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

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

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

The QoS influences the core threads are placed on https://developer.apple.com/documentation/apple-silicon/tuni....

You can tell something to run on e-core just not p-cores

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

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

Reply on news.ycombinator.com