Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ghostty 1.0

ghostty.org

Post reply on HN
Print view View original

681–690 of 719 posts

Re: Ghostty 1.0

#681

Post by marginalia_nu »

Gormo wrote: post #545
nateb2022 wrote: post #237

Earlier quoted context omitted.

> The big picture of "native" is that Ghostty is designed to look, feel, and behave like you expect an application to behave in your desktop environment. > On macOS, the GUI is written in Swift and uses AppKit and SwiftUI. ( https://ghostty.org/docs/about#native )

I'm using Linux with Xfce, but it seems to be locked into a Gnome-like look and feel, with header bars and CSDs that can't be disabled in favor of standard title bars and menus, so it's actually very inconsistent with the rest of my desktop environment.

I was looking into this recently. If you add this to the config, it'll blend in better with XFCE.

  window-theme = system
  gtk-titlebar = false
  gtk-wide-tabs = false
  gtk-adwaita = false
Dunno if anyone will see this comment, but if they do, here is the solution :D

Re: Ghostty 1.0

#682

Post by nvlled »

marginalia_nu wrote: post #681
Gormo wrote: post #545

Earlier quoted context omitted.

I'm using Linux with Xfce, but it seems to be locked into a Gnome-like look and feel, with header bars and CSDs that can't be disabled in favor of standard title bars and menus, so it's actually very inconsistent with the rest of my desktop environment.

I was looking into this recently. If you add this to the config, it'll blend in better with XFCE. window-theme = system gtk-titlebar = false gtk-wide-tabs = false gtk-adwaita = false Dunno if anyone will see this comment, but if they do, here is the solution :D

Thanks, ghostty looked really off in KDE by default.

Re: Ghostty 1.0

#683

Post by moktavizen »

mitchellh wrote: post #624
dsjkvf wrote: post #615

Earlier quoted context omitted.

[dead]

These benchmarks are all flawed. You can't measure input latency properly without a camera (or pixel access to the screen but then have to be careful it's not impacting your benchmark). The latency benchmark is just testing VT IO throughput for a specific zsh prompt. Not at all related to input latency. The plaintext IO benchmark is suspiciously slow for both Alacritty and Ghostty relative to Kitty. I ran the same on…

Author here, I will try to implement your suggestions. I made the benchmarks out of curiosity and excitement for ghostty release and never intended to pick on any specific terminal. Considering it's first initial release (1.0) ghostty performance is very good and I'm sure it will improve even more given a few months. I know ghostty doesn't just focus on performance, it excels in other area like utilizing native components and having a growing community that is very supportive.

Re: Ghostty 1.0

#684

Post by ckrailo »

navigate8310 wrote: post #204

Any love for Windows. I'm getting restless to ditch putty but unable to find any good emulator that has select and login style of management screen.

I've been happy enough with Microsoft Terminal instead of PuTTY (and I appreciate the open source github repo). If you're comfortable with editing JSON files, you can save the SSH connections as profiles so you can click to open a new tab to whatever SSH session (or WSL setup, or Powershell setup) you want. Example: https://www.howtogeek.com/devops/how-to-set-up-custom-ssh-pr...

Re: Ghostty 1.0

#685

Post by rauanm »

vrnvu wrote: post #517
rauanm wrote: post #502

I tried to install and play around with it, it's really nice. Took a bit of tinkering to set a theme and my favourite Pragmata Pro, but what ultimately annoys me is the lack of 'turnkey' selecting for text. When I run `Cmd + A`, I want my terminal to make a full text selection of an entered command, not of the screen content. Or when I run `Option + Shift + Arrow left/right`, I want to select words from an entered co…

Cmd+A to select the entered command isn't standard. You could try: - Ctrl+A: Move to the beginning of the line. - Ctrl+E: Move to the end of the line. - Ctrl+K: Cut the command from the cursor position to the end. - Ctrl+U: Cut the command from the cursor to the beginning of the line. - Ctrl+Y: Paste the text back. This should work in all terminals.

You're just forcing me to be a vimer at this point. :)

By normal macos experience I mean key bindings for regular text fields, not regular terminal (whatever they're supposed to be). Afaik, Warp was the first one ever to treat terminal input as a regular text field input.

Re: Ghostty 1.0

#686

Post by arghwhat »

mitchellh wrote: post #617
epcoa wrote: post #585

Earlier quoted context omitted.

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

We do a full redraw but do damage tracking ("dirty tracking" for us) on the cell state so we only rebuild the GPU state that changed. The CPU time to rebuild a frame is way more expensive than the mostly non-existent GPU time to render a frame since our render pipeline is so cheap. As I said in another thread, this ain't a AAA game. Shading a text grid is basically free on the GPU lol.

It's actually not at all free, even if you're barely using the shading capacity. The issue is that you keep the power-hungry shader units on, whereas when truly idle their power is cut. Battery life is all about letting hardware turn off entirely.

Also, if you do damage tracking, make sure to report it to the display server so they can avoid doing more expensive work blending several sources together, and in case of certain GPUs and certain scanout modes, also more efficient scanout. Depending on your choice of APIs, that would be something like eglSwapBuffersWithDamage, wl_surface_damage_buffer, and so forth.

Re: Ghostty 1.0

#687

Post by epcoa »

arghwhat wrote: post #686
mitchellh wrote: post #617

Earlier quoted context omitted.

We do a full redraw but do damage tracking ("dirty tracking" for us) on the cell state so we only rebuild the GPU state that changed. The CPU time to rebuild a frame is way more expensive than the mostly non-existent GPU time to render a frame since our render pipeline is so cheap. As I said in another thread, this ain't a AAA game. Shading a text grid is basically free on the GPU lol.

It's actually not at all free, even if you're barely using the shading capacity. The issue is that you keep the power-hungry shader units on , whereas when truly idle their power is cut. Battery life is all about letting hardware turn off entirely. Also, if you do damage tracking, make sure to report it to the display server so they can avoid doing more expensive work blending several sources together, and in case of…

> The issue is that you keep the power-hungry shader units on, whereas when truly idle their power is cut.

Even in the most perverse scenario of a single cell update the load for a terminal is still bursty enough that it's not like the GPU doesn't enter some power saving states. Running intel_gpu_top in kytty with a 100ms update is at least suggestive, it never drops below 90% RC6 (even at 50ms, which is a completely uselessly fast update rate we're still in the high 80s). If you're updating faster than 100ms legitimately, it's probably video or animation that is updating a large percentage of the display area anyway. The overall time my terminal is doing some animation while on battery is low enough that in practice it just doesn't matter.

https://en.wikipedia.org/wiki/Amdahl%27s_law

The problem you're up against is that, maybe if this was optimized most people would get 2 or 3 (or even 10) more minutes on a 12 hour battery life or something. No one really cares. Maybe they should, but they don't. And there's plenty of other suck in their power budget.

You make it sound like a binary power saving scenario, but it tends to be more nuanced in practice.

Most people run their terminal opaque, most display systems optimize this common case.

> Also, if you do damage tracking, make sure to report it to the display server

I'm not unsympathetic to your point of view. But I am skeptical that the power savings for most use cases ends up being much of a big deal in practice for most people (even accepting there may be some annoying edge cases that annoy some). I am interested in this topic, but I am still awaiting an example of a GPU accelerated terminal emulator that works this way to even make a real world comparison.

Re: Ghostty 1.0

#688

Post by CarlitosHighway »

adamdecaf wrote: post #664
CarlitosHighway wrote: post #657

Love this in theory but the first time user experience could be improved: $ brew install ghostty Launch it, don't configure anything, in the new terminal window then enter: $ lazydocker Response: 2024/12/28 09:04:42 An error occurred! Please create an issue at https://github.com/jesseduffield/lazydocker/issues *exec.ExitError exit status 1 /home/runner/work/lazydocker/lazydocker/main.go:96 (0x9397d7) /opt/hostedtoolc…

That’s a problem with lazydocker, not ghostty. Maybe contribute to https://github.com/jesseduffield/lazydocker/issues/610 ?

Do you have anything to back up this claim? Because it only crashes in Ghostty, and no other terminal emu I tried it in.

Anyway, not my problem, I will just wait until it's fixed and if not, then I'll use one of the gazillion other ones that work 100%.

Re: Ghostty 1.0

#689

Post by gigatexal »

gigatexal wrote: post #112
modernerd wrote: post #108

Earlier quoted context omitted.

https://ghostty.org/docs/config On macOS, pressing ⌘+comma with Ghostty in focus opens the config file. Quit and reopen Ghostty to load the updated config (or bind another key to the reload_config action: https://ghostty.org/docs/config/keybind/reference#reload_con... ). Keybinds are explained here: https://ghostty.org/docs/config/reference#keybind

I just saw this https://ghostty.org/docs/config and was coming to update my post when I saw your comment. Thank you! Imma try out ghostty, WezTerm, and Rio thanks to this thread. And why not use them all. For terminal minded folks we are surely spoiled.

Brief update: I really really like rio. Out of the box it has the best theme, best setup. It’s fast. Pretty. I like it tons.

Ghostty is nice. Haven’t had much time with WezTerm.

Re: Ghostty 1.0

#690

Post by arghwhat »

epcoa wrote: post #687
arghwhat wrote: post #686

Earlier quoted context omitted.

It's actually not at all free, even if you're barely using the shading capacity. The issue is that you keep the power-hungry shader units on , whereas when truly idle their power is cut. Battery life is all about letting hardware turn off entirely. Also, if you do damage tracking, make sure to report it to the display server so they can avoid doing more expensive work blending several sources together, and in case of…

> The issue is that you keep the power-hungry shader units on, whereas when truly idle their power is cut. Even in the most perverse scenario of a single cell update the load for a terminal is still bursty enough that it's not like the GPU doesn't enter some power saving states. Running intel_gpu_top in kytty with a 100ms update is at least suggestive, it never drops below 90% RC6 (even at 50ms, which is a completely…

It is very nuanced, but it's important to realize how small the power budget is and how just tens of milliwatt here and there make a huge difference.

To get over 12 hours of battery life out of a 60 Wh battery - which isn't impressive nowadays with laptops rocking 20+ hours - you need to stay below 5 watts of battery draw on average, and considering that the machine will likely do some actual computation occasionally, you'll need to idle closer to 2-3 watts at the battery including the monitor and any conversion losses.

The really big gains in battery life are from cutting tens to hundreds of mW off things at the bottom by keeping hardware off and using fixed function hardware like e.g. avoiding rendering and doing direct scanout and using partial panel self refresh. Execution units do not turn on and off instantly so pinging them even briefly is bad, and the entire system needs to be aligned with the goal of only using them when necessary for them to stay off.

Efforts like libliftoff to do efficient plane offload to avoid render steps in the display server can save in the area of half a watt or more, but it's not a whole lot of help if applications don't do their part.

Bigger GPUs than your iGPU (or even just later iGPUs) will also likely see even bigger impacts, as their bigger shader units are likely much hungrier.

(As an aside, I am not a fan of kitty - they have really weird frame management and terrible recommendations on their wiki. Foot, alacritty or if ghostty turns out good, maybe even that would be better suggestions. Note that comparing to foot can give a wrong image, as CPU-based rendering pushes work to the display server and gives the illusion of being faster and more efficient than it really is.)

Post reply on HN