On the second display quick terminal view is scrambled until click or type event

[dmotylev]

I don't know how to explain it clearly, and a video is better than a thousand words in this case.

ghostty-bug-20241119.mov

I have seen it on the main window as well, however I was not able to reproduce it stable.

Steps to reproduce

• macOS 15.1
• Attach a second display as an extension
• Switch to any window in a space on this display
• Invoke Quick Terminal by keyboard short-cut; sometimes repeat this step a few times
• View fixes itself upon any input event: click or typing (both on video; "click" happened when the mouse cursor is moving in the view on video)

Ghostty version and config

❯ ghostty +version
Ghostty 0.1.0-main+e54ae31d

Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.none
  - font engine: font.main.Backend.coretext
  - renderer   : renderer.Metal
  - libxev     : main.Backend.kqueue

❯ sed -E '/^$/d; /^#/d' ~/.config/ghostty/config
command = /opt/homebrew/bin/fish
shell-integration-features = cursor,sudo
font-size = 15
font-family = JetBrainsMono Nerd Font Mono
copy-on-select = clipboard
clipboard-paste-protection = true
clipboard-trim-trailing-spaces = true
macos-option-as-alt = true
window-save-state = always
window-new-tab-position = end
unfocused-split-fill = 000000
mouse-hide-while-typing = false
window-step-resize = false
theme = Smyck
minimum-contrast = 1.0
keybind = opt+up=jump_to_prompt:-1
keybind = opt+down=jump_to_prompt:+1
keybind = cmd+ctrl+left=resize_split:left,20
keybind = cmd+ctrl+right=resize_split:right,20
keybind = cmd+ctrl+up=resize_split:up,20
keybind = cmd+ctrl+down=resize_split:down,20
quick-terminal-screen = mouse
quick-terminal-position = top
keybind = global:cmd+`=toggle_quick_terminal

[mitchellh]

I would normally make this a discussion but this looks like something somewhat familiar. This looks like our Metal textures are... wrong. Either wrong scale, or our x/y is wrong, or something. It's not something I've ever seen in a production build but it's something I've seen while working on the font subsystem.

I haven't tried to reproduce this yet.

Are your two displays a different content scale perhaps?

[dmotylev]

Are your two displays a different content scale perhaps?

They are:

• Main (built-in) has a resolution 3024 × 1964 scaled to 1800 x 1169 (ironically, they call it More Space)
• Second has a resolution 3840 × 2160 (native) scaled to 3840 × 2160

I would consider this bug minor if it were "recovering" without any additional input. But it is annoying to have on a quick terminal, as I often use it for something ad hoc and then peek for the result over time.

[dmotylev]

I can not reproduce it anymore. Here is the current context:

• MacOS is 15.1.1 (24B91)
• Ghostty is 0.1.0-main+4c2d4620

[flou]

This happened to me as well a few times today, I haven't found a way to reproduce it yet.

[blieusong]

Hi, if it helps I'm able to reproduce a similar glitch.

Steps to reproduce

I start with a two tabs terminal on the built-in screen (which is hDPI):

Then I drag the tab out to my external monitor:

ghostty_bug.mov

Setup

• Macbook Pro M2 with 32GB memory
• external monitor Samsung C49RG9x at 5120x1440
• Sequoia 15.1.1

$ ghostty +version
Ghostty 0.1.0-main+466d094c

Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.none
  - font engine: font.main.Backend.coretext
  - renderer   : renderer.Metal
  - libxev     : main.Backend.kqueue

PS: Great app by the way. Many thanks!

[BernieSumption]

This might be a useful bit of the puzzle. I have a primary high res screen (laptop monitor) and 2 external low res displays.

Quick terminal seems to work by initialising the terminal off screen and animating it down onto the screen. When monitors are arranged vertically and you call up the quick terminal on the lower screen, you see it appear on the upper screen first.

This bug happens in two scenarios:

1. two screens are stacked vertically AND the quick terminal is called up on the lower screen (therefore initialises on the upper screen and animates down) AND the two screens are different resolutions
2. quick terminal is called up on a low-res screen (therefore initialises in the space not covered by any screen) AND there is not another low res screen immediately above it

The large swcreens are low res, small screen high res.

Scenario 1

• Happens on the landscape low res screen
• Does not happen on the portrait low res screen because the screen above it is same res
• Does not happen on the high res screen because there is no other screen immediately above it

Scenario 2

• Happens on both low res screens because there is no other low res screen immediately above
• Happens on the high res screen because there is a low res screen immediately above

Assuming that the issue here is caused by moving the terminal between screens of a different resolution, might this be fixed by causing the terminal to be initialised for the resolution of the screen that it's going to animate onto, rather than the screen that it first appears on?

[mitchellh]

Assuming that the issue here is caused by moving the terminal between screens of a different resolution, might this be fixed by causing the terminal to be initialised for the resolution of the screen that it's going to animate onto, rather than the screen that it first appears on?

This is good insight thank you. As I noted in my first response my immediate intuition was a scale issue, since that has caused bugs that looked like this in the past.

Right now the terminal itself is unaware its being animated. The animation happens much higher level (at the windowing level) and we rely on macOS events to notify us the screen changed for DPI changes. That's the same notification we use when you say... drag a window from one screen to another.

I think one of my first questions here if your assessment is true is why that notification isn't being triggered automatically during (or even after) the animation. And if it's not being triggered, one fix is simply to force it ourselves.

"Force it" is roughly your suggestion, though you suggest doing it at the beginning of the animation, which also is fine. I think the "when" depends on what macOS is doing with notifications. i.e. if they're sending a notification but its the wrong screen because its just prior to animation end, then doing it at the beginning won't solve the issue. Etc etc.

If anyone wants to take a look at this, the callback should be somewhere in SurfaceView_AppKit. I realize that's a big file but search for I think content_scale. The actual quick terminal stuff is all in the "Quick Terminal" features folder.

[mitchellh]

I just merged #3091. I'm unable to reproduce this (I guess both my displays are too similar and even changing resolution its triggering it), but I suspect it might be something like the fix I just merged. Can anyone update Ghostty and verify if this is resolved? The new build should come out in ~30 minutes, just check the SHA in the about window that it is after #3091 merged!

[BernieSumption]

I can still reproduce the issue on build b1756b93.

I've requested access to http://ghostty.org/docs/install/build, if I get time I'll make a build and see if I can debug the issue and get any more insight.

FWIW since the terminal re-renders correctly as soon as I type anything this is a mild eyesore but not stopping me from using Quick Terminal.

[mitchellh]

Alright thanks. Yeah, it's curious it fixes on input. There's clearly some event we're missing to redraw or get the correct content scale and I haven't figured it out yet.

[AMMullan]

I've just raised #4483 but TBH I think it might be heavily related. If there's anything useful in that discussion item then great otherwise we can close that one I think?

[charlesnicholson]

I raised #4197 which looks similar- I don't see the same graphical corruption but the font spacing gets very weird.

[kbherbert]

Building upon the repro steps of @BernieSumption, I consistently reproduce this with my desk setup, simply by dragging Ghostty between a hi-dpi monitor and a "standard" monitor. I have an ultra wide monitor, with my MacBook Pro M1 off to the side. The MacBook is set to the default hi-dpi mode (1728 x 1117) which is 254ppi. Whereas my ultra wide monitor is a QHD (3440x1440) which is 109ppi.

And as mentioned, clicking/scrolling/etc causes it to redraw and fix itself.

[Cyclenerd]

I have the same problem. However, I only have one monitor connected to my Mac Mini M1. When I turn the monitor off and on again, I also have the broken characters.

Sometimes not in the active Ghostty tab but in others tabs. Waiting or typing helps.

$ ghostty +version
Ghostty 1.0.1

Version
  - version: 1.0.1
  - channel: stable
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.none
  - font engine: font.main.Backend.coretext
  - renderer   : renderer.Metal
  - libxev     : main.Backend.kqueue

macOS: 14.7.1

Display settings:

[victordidenko]

I also have a similar issue.

Here is my system:

OS: macOS Sequoia 15.2 arm64
Host: MacBook Pro (14-inch, Nov 2023, Three Thunderbolt 4 ports)
Kernel: Darwin 24.2.0
Uptime: 16 days, 22 hours, 46 mins
Shell: fish 3.7.1
Display (Color LCD): 3600x2338 @ 120 Hz (as 1800x1169) in 14" [Built-in] *
Display (Redmi 27 NQ): 5120x2880 @ 60 Hz (as 2560x1440) in 27" [External]
Display (Redmi 27 NQ): 5120x2880 @ 60 Hz (as 2560x1440) in 27" [External]
Terminal: ghostty 1.0.1
CPU: Apple M3 Pro (12) @ 4.06 GHz
GPU: Apple M3 Pro (18) @ 1.38 GHz [Integrated]

Ghostty 1.0.1

Version
  - version: 1.0.1
  - channel: stable
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.none
  - font engine: font.main.Backend.coretext
  - renderer   : renderer.Metal
  - libxev     : main.Backend.kqueue

font-family = MesloLGM Nerd Font Mono
font-size = 13
font-feature = -calt
font-feature = -liga
font-feature = -dlig

theme = iTerm2 Pastel Dark Background
shell-integration-features = no-cursor
mouse-hide-while-typing = true

background-opacity = 0.9
background-blur-radius = 10
unfocused-split-opacity = 0.9
unfocused-split-fill = 444444

command = /opt/homebrew/bin/fish

macos-titlebar-style = tabs

window-height = 56
window-width = 190

copy-on-select = true

keybind = global:cmd+grave_accent=toggle_quick_terminal

I rarely turn off my laptop; I usually just switch off the displays, both internal and external. The issue is very rare, I don't know how to reproduce it, and typically occurs after turning the displays back on and logging into the system. Ghostty is always open on the first external monitor, and I don’t drag it between the internal and external displays. After I activate the Ghostty window (even without typing anything), all the text re-renders and looks fine again.

Additionally (if the issue is related to scaling), I use the tool BetterDisplay, which emulates (?) high resolution on external monitors.

[cova-fe]

I have to report the same behavior on my setup (m3 laptop+external screen). What I can add is that sometimes when the window is dragged across the screens ghostty simply crashes. What it happens is that the window size (char wise) is increased by a sizeable amount, say 50% when moving from the external monitor (bigger but lower res) to the internal laptop monitor. Resizing seems to happen pretty consistently on my side, so if you have suggestions I can try to collect more info.

[morganick]

I experienced this issue yesterday. I was working on my MacBook Pro laptop screen, closed the laptop, and plugged it into my external display (5k). When the screen came up the terminal was scrambled. If you interact with the terminal, it fixes itself.

MacOS: Sequoia 15.2

Ghostty
Version 1.0.1
Build 8696
Commit 3f7c3afa

Otherwise, the terminal has been swift and solid. 🙌

[victordidenko]

Sometimes it happens not for the whole Ghostty window, but inside single terminal. On a screenshot I caught there are two terminals (splits?), splited vertically, left one become crumbled, right one is good.

After activating all text become good again. Sometimes even just moving mouse above crumbled terminal fixes it.

[renegadevi]

Yes can confirm. When I connect my external monitor, this happens. Then when the window gets focused, then it's re-rendered correctly.

[nickkaltner]

I also have this issue, still in 1.1.

IT happens both on the quick terminal and the normal terminal.

i have 2 external 2k monitors and the laptop screen. I've only seen it on the external monitors.

The best way to reproduce is opening/closing the quick terminal a few times or switching screen focus and opening it.

any input to the terminal fixes it.

this is with an m1 max laptop with macos 15.2

[gdiazlo]

I believe I might hit this too.

btw, it would be awesome to be able to copy version/build info instead of capturing or typing it.

[peanball]

I have the same issue with today's tip based on 38908e0.

This is moving to the mac's built-in Retina display. On the right of this video is a 1440p standard resolution display. Both at 120hz.

M4 Pro Mac, in case that makes a difference for Metal?

Screen.Recording.2025-02-19.at.12.30.02.720p.mov

[oneslash]

In my case this happens when I put my mac to sleep and wake up.

I am not sure if this will help to reproduce it.