First Opening is Slow

[Tahinli]

Hi, thanks for Ghostty at the first step.

Opening Ghostty takes 2-3x times more then kitty, alacritty and wezterm.

My specs are:

10750H
1660ti driver version: 565.77
Fedora 41 & Hyprland

startup logs are here:

info: ghostty version=0.1.0-dev+0000000
info: ghostty build optimize=ReleaseFast
info: runtime=apprt.Runtime.gtk
info: font_backend=font.main.Backend.fontconfig_freetype
info: dependency harfbuzz=8.4.0
info: dependency fontconfig=21402
info: renderer=renderer.OpenGL
info: libxev backend=main.Backend.io_uring
info(os): setlocale from env result=en_GB.UTF-8
info(gtk): GTK version build=4.16.5 runtime=4.16.5
info: reading configuration file path=/home/tahinli/.config/ghostty/config
info(config): config has 'keybind = clear', all keybinds cleared
info(config): default shell source=env value=/bin/zsh
EGL API version 1.5 found
 - Vendor: NVIDIA
 - Version: 1.5
 - Device: /dev/dri/renderD128, 226 128
 - Client APIs: OpenGL_ES OpenGL
 - Extensions:
	EGL_ANDROID_native_fence_sync
	EGL_EXT_buffer_age
	EGL_EXT_client_sync
	EGL_EXT_create_context_robustness
	EGL_EXT_image_dma_buf_import
	EGL_EXT_image_dma_buf_import_modifiers
	EGL_EXT_output_base
	EGL_EXT_output_drm
	EGL_EXT_present_opaque
	EGL_EXT_protected_content
	EGL_EXT_stream_acquire_mode
	EGL_EXT_stream_consumer_egloutput
	EGL_EXT_sync_reuse
	EGL_IMG_context_priority
	EGL_KHR_config_attribs
	EGL_KHR_context_flush_control
	EGL_KHR_create_context
	EGL_KHR_create_context_no_error
	EGL_KHR_fence_sync
	EGL_KHR_get_all_proc_addresses
	EGL_KHR_gl_colorspace
	EGL_KHR_gl_renderbuffer_image
	EGL_KHR_gl_texture_2D_image
	EGL_KHR_gl_texture_3D_image
	EGL_KHR_gl_texture_cubemap_image
	EGL_KHR_image
	EGL_KHR_image_base
	EGL_KHR_no_config_context
	EGL_KHR_partial_update
	EGL_KHR_reusable_sync
	EGL_KHR_stream
	EGL_KHR_stream_attrib
	EGL_KHR_stream_consumer_gltexture
	EGL_KHR_stream_cross_process_fd
	EGL_KHR_stream_fifo
	EGL_KHR_stream_producer_eglsurface
	EGL_KHR_surfaceless_context
	EGL_KHR_swap_buffers_with_damage
	EGL_KHR_wait_sync
	EGL_MESA_image_dma_buf_export
	EGL_NV_nvrm_fence_sync
	EGL_NV_output_drm_flip_event
	EGL_NV_quadruple_buffer
	EGL_NV_robustness_video_memory_purge
	EGL_NV_stream_attrib
	EGL_NV_stream_consumer_eglimage
	EGL_NV_stream_consumer_gltexture_yuv
	EGL_NV_stream_cross_display
	EGL_NV_stream_cross_object
	EGL_NV_stream_cross_process
	EGL_NV_stream_cross_system
	EGL_NV_stream_dma
	EGL_NV_stream_fifo_next
	EGL_NV_stream_fifo_synchronous
	EGL_NV_stream_flush
	EGL_NV_stream_metadata
	EGL_NV_stream_origin
	EGL_NV_stream_remote
	EGL_NV_stream_reset
	EGL_NV_stream_socket
	EGL_NV_stream_socket_inet
	EGL_NV_stream_socket_unix
	EGL_NV_stream_sync
	EGL_NV_system_time
	EGL_NV_triple_buffer
	EGL_WL_bind_wayland_display
	EGL_WL_wayland_eglstream
 - Selected fbconfig: R8G8B8A8, depth 0, stencil 0
          high depth: none
Creating EGL context version 3.2 (debug:no, forward:no, legacy:no, es:no)
Using OpenGL backend EGL
Creating EGL context version 3.2 (debug:no, forward:no, legacy:no, es:no)
OpenGL version: 4.6 (core)
GLSL version: 4.60 NVIDIA
Max texture size: 32768
Enabled features (use GDK_GL_DISABLE env var to disable):
    debug: ✓
    unpack-subimage: ✓
    half-float: ✓
    sync: ✓
    base-instance: ✓
    buffer-storage: ✓
OpenGL version: 4.6 (core)
GLSL version: 4.60 NVIDIA
Max texture size: 32768
Enabled features (use GDK_GL_DISABLE env var to disable):
    debug: ✓
    unpack-subimage: ✓
    half-float: ✓
    sync: ✓
    base-instance: ✓
    buffer-storage: ✓
Creating EGL context version 3.3 (debug:no, forward:no, legacy:no, es:no)
OpenGL version: 4.6 (core)
GLSL version: 4.60 NVIDIA
Max texture size: 32768
Enabled features (use GDK_GL_DISABLE env var to disable):
    debug: ✓
    unpack-subimage: ✓
    half-float: ✓
    sync: ✓
    base-instance: ✓
    buffer-storage: ✓
info(grid): loaded OpenGL 4.6
info(io_exec): found Ghostty resources dir: /home/tahinli/.local/bin/share/ghostty
info(io_exec): shell integration automatically injected shell=termio.shell_integration.Shell.zsh
warning(gtk): unimplemented action=apprt.action.Action.Key.cell_size
warning(gtk): unimplemented action=apprt.action.Action.Key.size_limit
info(io_exec): started subcommand path=/bin/sh pid=100917
info(io_exec): subcommand cgroup=-
Creating EGL context version 3.2 (debug:no, forward:no, legacy:no, es:no)
OpenGL version: 4.6 (core)
GLSL version: 4.60 NVIDIA
Max texture size: 32768
Enabled features (use GDK_GL_DISABLE env var to disable):
    debug: ✓
    unpack-subimage: ✓
    half-float: ✓
    sync: ✓
    base-instance: ✓
    buffer-storage: ✓
Using fractional scale 1 for EGL window (960 523 => 960 523)
Using fractional scale 1 for EGL window (931 494 => 931 494)
info(grid): reallocating GPU buffer old=0 new=8
info(osc): unknown semantic prompts option: cl
warning(osc): invalid OSC command: 1337;SetUserVar=WEZTERM_PROG=
warning(osc): invalid OSC command: 1337;SetUserVar=WEZTERM_USER=dGFoaW5saQ==
warning(osc): invalid OSC command: 1337;SetUserVar=WEZTERM_IN_TMUX=MA==
warning(osc): invalid OSC command: 1337;SetUserVar=WEZTERM_HOST=dGZlZG9yYQ==
info(stream): OSC 1 (change icon) received and ignored icon=~
warning(stream): unimplemented OSC command: change_window_icon
warning(osc): invalid OSC command: 133;P;k=i
info(grid): reallocating GPU buffer old=8 new=38

(process:100894): Gdk-CRITICAL **: 01:00:59.439: gdk_event_get_modifier_state: assertion 'GDK_IS_EVENT (event)' failed

[mitchellh]

I converted to Q&A until more details are grabbed.

I would expect our first window startup time to be significantly slower than WezTerm or Kitty, but can't quantify that. We're using GTK, which is an extremely heavyweight GUI toolkit and initialization takes a lot of time.

I haven't compared to WezTerm or Kitty, but I know that simply initializing GTK (i.e. zero Ghostty code) is slower than foot's entire first paint startup time, for example. Nothing we can do about that.

So I'm just making this a Q&A to figure out if this is just GTK being GTK or if there is more to it.

As an aside our N=2+ window startup time should be extremely fast, competitive with WezTerm and Kitty, since GTK only initializes for the first window.

[mmirus]

Yep, that's exactly what I am doing currently as a workaround (and also using that flag in my sway keybinding to launch a terminal).

[mmirus]

Recapping some of the options:

1. Flip the logic to default to "ghostty was luanched from a desktop," and detect if it was not (e.g., ghostty -e), instead of the opposite.
2. Keep the logic as-is, but find additional ways to detect when ghostty was launched from a desktop.
3. Modify the .desktop file shipped with ghostty to explicitly include --gtk-single-instance=true, per @trygveaa above.*

Quite possibly, the third option (being explicit in the .desktop file) would be good to do in combination with any sort of automatic detection, if there aren't any obvious downsides.

*Note that this wouldn't solve for methods of launching ghostty that don't use the .desktop file. For example, it's common to have a global hotkey for launching a terminal. Users can include --gtk-single-instance=true explicitly when defining their keybinding, but an ideal solution wouldn't require users to know to do that.

[mitchellh]

These are all good options. I just want to note I'm reading these issues but working on catching up on some other things before doing anything. 😄

[mmirus]

Thanks, Mitchell. Super impressed with your responsiveness; I'm sure there's been a ton of chatter here following the launch and you have much bigger fish to fry than this topic.

[jcollie]

See #2442 for a discussion that uses DBus activation & systemd user units to set things up for much faster operation. I even recently discovered how to set up a global hotkey under Gnome that will open a new Ghostty window, even if Ghostty is not running.

[choucavalier]

I just started using ghostty, switching from foot (which does not support font ligatures).

This is the first thing I noticed. Foot opens instantly. Ghostty takes a lot of time to open (what feels like 1 second compared to foot).

This is a bit disappointing because startup time is really important for a terminal: we're spending our days opening terminals to run commands, at least that's my workflow.

Right now I feel like I have to wait on Ghostty to open and I feel like the software is slowing me down.

[rhodes-b]

This is the expected behavior as Mitchell has stated the workflow of ghostty is to keep it open for long periods of time
https://ghostty.org/docs/help/gtk-single-instance
above will significantly help after that first window. If you say the first window is still too slow you can run it without the GUI and keep it alive in the background with a command like this
ghostty --initial-window=false --quit-after-last-window-closed=false

[trygveaa]

I don't see any difference in startup time when using --gtk-single-instance=true. I first started one instance of ghostty with ghostty --gtk-single-instance=true. Then to measure startup time I'm running time ghostty --gtk-single-instance=true -e sh -c exit. This takes around 0.52 seconds on my machine (when using the powersave scaling governor) regardless of if I specify the gtk-single-instance option or not. This is on Arch Linux with the package from Arch's extra repo.

For reference, here's a comparison with some other terminal emulators:

Command	Time
time ghostty --gtk-single-instance=true -e sh -c exit	0.52 s
time ghostty -e sh -c exit	0.52 s
time kitty -e sh -c exit	0.46 s
time kitty -1 -e sh -c exit	0.07 s
time wezterm start --always-new-process -e sh -c exit	0.13 s
time wezterm start -e sh -c exit	0.08 s
time foot -e sh -c exit	0.09 s
time alacritty -e sh -c exit	0.21 s
time xterm -e sh -c exit	0.06 s

The faster time for kitty and wezterm is when an existing process is running and it opens in that. As far as I can see, foot, alacritty and xterm doesn't have support for that.

[SuperDuperDeou]

Can replicate on my machine. After running ghostty --gtk-single-instance=true --quit-after-last-window-closed=false --initial-window=false, ghostty --gtk-single-instance=true -e sh -c exit takes 0.40~0.45s, the same as simply ghostty -e sh -c exit

Additionally, ghostty --gtk-single-instance=true exits in 0.08~0.10s while another ghostty --gtk-single-instance is running.

Edit:
ghostty --gtk-single-instance=true -e sh does not attach to the existing Ghostty instance. Idk if it's intended behavior or not.

[trygveaa]

Ah! Yeah, I see now that if I just run ghostty --gtk-single-instance=true it's fast. I suppose I didn't test that, only tested from the launcher where it seemed slow (I'm using rofi on sway, so same issue as mentioned elsewhere in this thread) and with -e from another terminal.

I also realize that the times above for kitty and wezterm with an existing process aren't really that useful or comparable to the other times, as the processes exists immediately, so they don't measure how long it takes for the window and shell to be ready.

[SuperDuperDeou]

There is a lot to read, so I haven't gone through all the documentation yet, but, I finally stumbled upon something about -e.

       --initial-command
              This is the same as “command”, but only applies to the first terminal surface created when Ghostty starts.  Subsequent terminal surfaces will use the command con‐
              figuration.

              After  the first terminal surface is created (or closed), there is no way to run this initial command again automatically.  As such, setting this at runtime works
              but will only affect the next terminal surface if it is the first one ever created.

              If you’re using the ghostty CLI there is also a shortcut to set this with arguments directly: you can use the -e flag.  For example: ghostty -e fish --with --cus‐
              tom --args.  The -e flag automatically forces some other behaviors as well:

              • gtk-single-instance=false - This ensures that a new instance is launched and the CLI args are respected.

              • quit-after-last-window-closed=true - This ensures that  the  Ghostty  process  will  exit  when  the  command  exits.   Additionally,  the  quit-after-last-win‐
                dow-closed-delay is unset.

              • shell-integration=detect  (if  not none) - This prevents forcibly injecting any configured shell integration into the command’s environment.  With -e its highly
                unlikely that you’re executing a shell and forced shell integration is likely to cause problems (i.e. by wrapping your command in a  shell,  setting  env  vars,
                etc.).  This is a safety measure to prevent unexpected behavior.  If you want shell integration with a -e-executed command, you must either name your binary ap‐
                popriately or source the shell integration script manually.

So, -e overriding --gtk-single-instance is intended behavior. I have tried ghostty --gtk-single-instance=true --command="sh -c exit" but that just runs a standard $SHELL session, while ghostty --command="sh -c exit" behaves as expected.

[rhodes-b]

Ah! Yeah, I see now that if I just run ghostty --gtk-single-instance=true it's fast. I suppose I didn't test that, only tested from the launcher where it seemed slow (I'm using rofi on sway, so same issue as mentioned elsewhere in this thread) and with -e from another terminal.

I also realize that the times above for kitty and wezterm with an existing process aren't really that useful or comparable to the other times, as the processes exists immediately, so they don't measure how long it takes for the window and shell to be ready.

When ghostty launches a command with -e it wont use gtk-single-instance=true as described in the docs

[gptlang]

The initial posted issue mentioned using Hyprland.

ghostty uses launchedFromDesktop to determine if a shared gtk instance should be used.
Hyprland launches the process directly without using a .desktop file.
The solution is to set:

exec-once = ghostty --gtk-single-instance=true --quit-after-last-window-closed=false --initial-window=false

$terminal = ghostty --gtk-single-instance=true

in your Hyprland config.
This gets ghostty actually on par with kitty and actually faster than wezterm.

This feels good enough in the sense that going faster isn't really noticeable beyond this point, especially accounting for animations and such.

[justNeto]

This absolutely worked for me. Thank you!

[Sneethe]

Sorry but was this

$terminal = ghostty --gtk-single-instance=true

meant to be how ghotty is spawned? So for Hyprland that would be:
bind = Super, Return, exec, ghostty --gtk-single-instance=true

[gptlang]

Ah by default it goes like this:

bind = $mainMod, Q, exec, $terminal

What you wrote works too. I have multiple keybinds to the terminal, one of them directly spawning tmux in it and it helps not having to repeat the args