Fullscreen Ghostty has red/white reverse "E" artifacts on some Intel Mac laptops

[sitsofe]

Description of the problem
When ghostty is sent fullscreen strange red lines appear behind text but in front of the background.

Steps to reproduce

1. Download Ghostty from https://ghostty.org/download .
2. Open the downloaded DMG.
3. Double click Ghostty.app.
4. Click the green maximise button.

Expected result
Window to go fullscreen and remain with a black background.

Actual result
Window goes fullscreen but strange red lines appear behind text but in front of the black background.

How reproducible is the issue?
The issue is reproducible every time.

Version information
Ghostty 1.0.1 Build 8696
macOS 15.2 (24C101)
Intel MacBook Pro 2020

Additional information
There are no artifacts present when Ghostty is started after step 3. When Ghostty is un-fullscreened the artifacts disappear. If the Ghostty window is made as big as possible but without going fullscreen (by double clicking the titlebar) no artifacts are seen. If an external display is attached via USB-C, the fullscreen artifacts don't occur even when Ghostty is only being fullscreened only on the laptop's internal display. While the artifacts are showing in fullscreen if the right mouse button is pressed and “Split Right” is then selected then the artifacts will only be on the pane on the left. This issue might be a duplicate of #1816 .

Screenshot below:

Zoomed close-up of artifacts:

[sitsofe]

I've just noticed this in the linked issue:

This could also be an Intel Metal issue, we've also found numerous of those bugs [...] we'll likely also drop support for Intel come this fall since I expect Apple to also get there.

I was unaware that Intel Macs were unsupported... Could I gently suggest that Ghostty should not be built as universal binary to make this clearer?

[mitchellh]

Intel is supported, we didn't drop support, but to the best of our knowledge this is an Intel Metal GPU driver issue. This doesn't happen for all Intel users and Ghostty works great on Intel Macs otherwise.

[sitsofe]

@mitchellh Thank you for the correction!

[sitsofe]

@mitchellh do you know if the issue has already been reported to Apple? I know it's a long shot but I'm thinking of sending something via Feedback Assistant if I'm not going to duplicate work someone else has already done...

[sitsofe]

I've opened ticket FB16349206 via Feedback Assistant for this but that's no guarantee Apple will investigate the problem...

[phil-r]

I have the same issue, interestingly adding new pane and/or tabs eventually fixes it. Also bug goes away while trying to screen record 🤯

[sitsofe]

@phil-r do you have an Intel Mac too?

[sitsofe]

@phil-r did you see the question above?

[phil-r]

Hey, yep, intel as well

Details

[sitsofe]

@phil-r macOS 15.2 too?

[sitsofe]

Something I forgot to say: as mentioned in the original ticket if an external screen is hooked up the fullscreen artifacts don't occur even though Ghostty is being fullscreened on the laptop's internal display.

[okuuva]

I have the same problem, though my artifacts are white:

The color might be related to the theme in use, or different chipsets have slightly different problems. And like @phil-r said, adding another tab "fixes" (more likely hides) the issue. Using the second tab helps on my machine.
(Unfortunately still) Rocking an Intel chip here as well:

18:22:58 󰈺  ❯ 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

[sitsofe]

@okuuva are you running Ghostty on the laptop's internal display with no external monitors attached?

[okuuva]

Yes I am. Haven't tried with external monitors yet.

[sitsofe]

I'm going to re-title this ticket because:

• @okuuva's artifacts aren't red (but when you zoom in you can see they are the same shape as mine)
• So far it seems to be happening on Intel MacBook Pros
• It happens on the laptop's internal display

[okuuva]

I just tried out a different theme (rose-pine-dawn mentioned in #3991) and with that the artifacts were red. Didn't even have to restart the terminal, reloading the config immediately changed the artifact color. So I don't think the actual color matters here, just using the internal display on Intel MBP. Sounds very much like a Metal driver bug.

[okuuva]

Ok, this is a bit ridiculous but the problem just suddenly went away for me and I can't get it to reproduce anymore.

I was playing around with my ghostty config and decided to move everything under a single file from multiple different files since it ended up being so short that splitting it up didn't really make sense. I also disabled ligatures, by switching to a NL variant of JetBrainsMono Nerd Font Mono and after some confusion also set -calt (really don't know why and how ghostty renders some ligatures even for an NL font but that's another topic entirely). Then after restarting Ghostty while trying to figure out what was going on with the ligatures, the artifacts didn't show up anymore. Not even after rolling back my ghostty config and restarting the Mac.

Maybe disabling the ligatures slapped some sense into the GPU drivers or something? Or dropping secondary backup font from the config helped somehow? Or the combination of the two? Neither would explain why the problem doesn't come back after reverting the changes and restarting the computer though...

Oh well. Here's my current config for reference. I'll report back if the problem resurfaces.

My current config

# fuctionality
command = /run/current-system/sw/bin/fish --login --interactive
shell-integration-features = sudo

# font
font-family = "JetBrainsMonoNL Nerd Font Mono"  # no ligatures -version, and disable code ligatures explicitly
font-size = 16
font-feature = -calt

# appearance
theme = light:Material,dark:MaterialDarker
cursor-invert-fg-bg = true
fullscreen = true

# quick terminal (drop-down terminal, quake terminal)
quick-terminal-position = bottom
quick-terminal-animation-duration = 0.1
quick-terminal-autohide = false

# keybinds
keybind = global:cmd+grave_accent=toggle_quick_terminal
keybind = global:cmd+ä=toggle_quick_terminal
keybind = global:cmd+<=toggle_quick_terminal
# TODO: figure out how to use IntlBackslash:
# https://github.com/ghostty-org/ghostty/blob/c8950d376ab3be13fbd9a19317163075f4feddbc/src/input/keycodes.zig#L348
# keybind = global:cmd+physical:IntlBackslash=toggle_quick_terminal
# keybind = global:cmd+IntlBackslash=toggle_quick_terminal

[sitsofe]

Odd! I tried your config and the problem is still happening for me. I'm assuming you still don't have any external screens attached?

[okuuva]

Yeah, that was a long shot, too bad it didn't solve it for you. I would really like to figure out a reliable way to reproduce it because clearly something helps, meaning there could be a feasible workaround available.

And yeah, still no external monitors in use. Haven't even connected one yet since I installed Ghostty.

[okuuva]

Ok, the problem resurfaced and now I know what originally "helped".

If you have the keyboard viewer open (even minimized and dragged to the corner, barely visible, or completely hidden by dwell corner) before you launch Ghostty, the artifacts do not appear. But if you at any point close the keyboard viewer (either form the X in the top left corner of it or selecting "Hide Keyboard Viewer" from the keyboard menu in the top menu) the artifacts reappear. Reopening the keyboard viewer doesn't help, you need to quit Ghostty, reopen the viewer and then reopen Ghostty.

Here's a video demo showing what I mean. Note that artifacts wouldn't show up during screen recording anyway, but with this keyboard viewer hack they don't show up even when screen recording is not on.

Screen.Recording.2025-01-07.at.15.27.39.mp4

[link108]

just found this thread, bummer to hear it likely won't be worked on. FWIW I'm on a 2020 macbook pro, macos version 15.2, running ghostty in full screen (no tabs or split panes). Once a pane has the red artifacts, they persist after splitting the pane or leaving full screen. I was running macos 15.1 until I saw this thread mention metal driver issues, I updated to macos 15.2, but it the issue still remains.

[sitsofe]

(Unrelated to Ghostty: If you are a 2020 Intel Macbook Pro owner could you take a look at this Google Chrome preventing proper sleep on 2020 Intel MacBook Pros gist and post a comment on the gist (and not here in the Ghostty discussion!) if you are able to reproduce the problem described within. Thanks!)

[link108]

I may have found a workaround to this, I was trying out custom shaders and noticed when I had a custom shader applied, I no longer saw the artifacts.
I used the following shader as a passthrough

void mainImage(out vec4 fragColor, in vec2 fragCoord)
{
    fragColor = texture(iChannel0, fragCoord / iResolution.xy);
}

[okuuva]

That worked for me too! Thanks a ton!

[okuuva]

While the artifacts have stayed away, I noticed that sometimes when I switch to the native fullscreen space where Ghostty is running the window flashes rapidly a couple (3-5) of times before settling down. I remember that happening earlier when the artifacts appeared to the screen. Might be a separate issue though, just happened to happen at the same time as the artifacts before. Just thought to report it as the two seem related.

[mitchellh]

I want to add a note after the fact that the assumption based on past issues is that this is an Intel GPU driver or Metal issue because we weren't able to find any other smoking guns.

Another possible issue here is a data alignment issue with our Metal buffer data. We align everything according to the shader language specification already though: https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf

This is what led me to believe its a driver bug. I don't have any Intel macs anymore (I haven't owned one in a couple years) so I can't reproduce this to submit an Apple Feedback issue. I've also heard through the grapevine (unconfirmed) from an Apple insider that Intel issues like this are basically completely deprioritized as the list of supported Intel machines is dwindling. Who knows.

In any case, if someone does figure out a way around this, I'd be happy to enshrine it in code, but it also needs to be explained reasonably well since I can't test it and there are a number of Intel mac users who DON'T have this issue too.

[sitsofe]

@mitchellh As mentioned in #3352 (reply in thread) I've filed Feedback issue FB16349206 with Apple but is there anything extra I should add to it? Also thanks for posting about it's likely priority within Apple.

there are a number of Intel mac users who DON'T have this issue too

From what I've read thus far the only people who seem to hit this issue have 2020 Intel Mac laptops running on (non-discrete) Intel GPUs. If you are reading this and are seeing the same issue but don't have this combination it would be useful for you to post a comment so we can widen the list of problem machines.

[link108]

In any case, if someone does figure out a way around this, I'd be happy to enshrine it in code, but it also needs to be explained reasonably well since I can't test it and there are a number of Intel mac users who DON'T have this issue too.

Very much agree, I don't know how/why the fix I provided above works or if it even solves the issue for all users who hit this issue 💯