Live data from Hacker News

Ghostty 1.0

ghostty.org

611–620 of 719 posts

Re: Ghostty 1.0

#611

- xterm still feel faster to me. - some visual artifacts with the gtk menu - sometimes prompt got clear when openning 2nd / 3rd windows - cant get keybinding quick toggle to work

> - some visual artifacts with the gtk menu

You need a compositor. picom works.

For a proper "native i3 experience" I recommend setting gtk-titlebar=false and unbinding tab/pane management keybinds. I already have a window manager, I don't need a second one.

I also had to disable adwaita because when it's enabled closing a shell with ^D closes all open windows, sometimes it leaves an empty window instead.

> - xterm still feel faster to me.

lxterminal also launches 6 times faster, I guess on a slow laptop without a dedicated GPU these terminals are not the most efficient option.

Re: Ghostty 1.0

#612

I have a traumatic experience with GPU-based GUI. Long time ago I tried to run Ubuntu in a VM, and they switched to GPU-based rendering. But as VM doesn't have a GPU, the system fell back to something called "llvmpipe". The result was that the widgets reacted approximately with 30 second lag to every action. So what I am asking, if you are making a GPU-based rendering toolkit, please write also SIMD software fallback…

I am asking this in good faith Why would you not ssh?

Because I wanted to see how a new Ubuntu looked. Not to do something useful.

Re: Ghostty 1.0

#613

I have a traumatic experience with GPU-based GUI. Long time ago I tried to run Ubuntu in a VM, and they switched to GPU-based rendering. But as VM doesn't have a GPU, the system fell back to something called "llvmpipe". The result was that the widgets reacted approximately with 30 second lag to every action. So what I am asking, if you are making a GPU-based rendering toolkit, please write also SIMD software fallback…

I am asking this in good faith Why would you not ssh?

Also to SSH into a VM you need to setup a second network card and to do this you need at least log into a text console.

Re: Ghostty 1.0

#614

I initially scoffed when I read "platform-native UI" as I've found programs made in Electron typically proclaim something similar when they are anything but native, so when I saw it used GTK for Linux (SwiftUI for MacOS) my interests were piqued. Always fun to mess around with new terminal emulators. edit: alas, it doesn't support bitmap fonts..

Looks like a very nice project overall. I was initially interested in the "native" UI but after trying Ghostty I think I've realised that in a terminal app I actually want all the UI to be terminal/TUI based within the terminal itself. This is a personal preference I've discovered rather than a criticism of Ghostty. It seems fast and really nice otherwise, so I'll keep fiddling with it, but so far I still prefer, for…

Yeah I also searched for a quick select in ghostty while checking now. I am probably too deep in wezterm with my lua configuration anyway, but still.

Re: Ghostty 1.0

#615
post #64

After a quick test this looks incredibly good and fast. I'll use it as a terminal for the next weeks to see how it goes, but I have good feelings. Thank you so much for writing it. EDIT: WOOOW, for me this is going to be a game changer. I was just working at Redis stuff outputting a ton of debugging info and results, and normally the terminal was the bottleneck, and here instead it printed half million of results in…

[dead]

Re: Ghostty 1.0

#617
post #585

Earlier quoted context omitted.

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…

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.

Re: Ghostty 1.0

#618
I wanted something as fast as Alacritty that had native tabs, could divide horizontal/vertical without tmux. And this seems like it!

Re: Ghostty 1.0

#619
post #572

Earlier quoted context omitted.

Is iTerm2 noticeably slow? I just use the built in Terminal app and I can’t imagine “speed” being a reason to switch away from it. (There is no lack of speed.)

The reason I switched from iTerm2 is it took multiple seconds to resize a window on macOS. I use Rectangle to resize windows, and by default my shortcut for "put this window on the left half" cycles through window sizes when the window is already on the left. So a common workflow is to tap Hyper-J to move a window to the left half, then make it the left third, then the left two thirds of the screen. This is fine for…

I’ve noticed that too when the scroll back buffer is particularly long. iTerm seems to then reflow from the beginning, which can take a while.

I keep using a lot of fresh tabs all the time and iTerm resizes instantly via Rectangle for me.

Ghostty was a bit more sluggish in resizing on an Intel Mac than iTerm in the current latest versions.

Re: Ghostty 1.0

#620
To be honest, I don't "get" ghostty. I am not really seeing how this is so much better than the GNOME terminal that ships with my Linux distro.

A lot of people are claiming that ghostty is "faster." I watched the lightning talk where the author claims that catting files and binaries is faster.

I tried this against ghostty itself after building with zig build -Doptimize=ReleaseFast, using: time cat ghostty.

In GNOME terminal, it took 3.340s. In ghostty, it took 16.947s. I must be doing something wrong?

Post reply on HN