ghostty-org
Initial window size incorrect with respect to window padding
A brand new Ghostty window calculates the initial window size wrong with respect to window padding, at least on macOS. The result is a new window has extra padding.
My configuration going into this:
- 2x DPI screen
window-step-resize = true, decoration and other settings at defaults though I turned off the macos shadow for debugging- Grid Size of 80 columns
- Cell Size of 16px × 31px
- Note that this means the cell grid is 1280px wide
What I'm seeing:
If I set window-padding-x = 0, the viewport is sized perfectly such that there is no horizontal padding.
Surface Info:
| Dimensions | Value |
|---|---|
| Screen Size | 1280px × 350px |
| Window Padding | T=4 B=4 L=0 R=0 px |
Screen width of 1280px matches cell grid, so no extra padding.
Screenshot
If I set window-padding-x = 1, the viewport has 2pt/4px extra padding on the right.
| Dimensions | Value |
|---|---|
| Screen Size | 1288px × 350px |
| Window Padding | T=4 B=4 L=2 R=2 px |
Expected screen width was 1284px (2px + 1280px + 2px), so at 1288px there's an extra 4px on the right (interesting that Surface Info doesn't report this anywhere)
Screenshot
If I set window-padding-x = 2, the viewport has 4pt/8px extra padding on the right.
| Dimensions | Value |
|---|---|
| Screen Size | 1296px × 350px |
| Window Padding | T=4 B=4 L=4 R=4 px |
Expected screen width was 1288px (4px + 1280px + 4px), so at 1296px there's an extra 8px on the right.
Screenshot
Additional info
I used the Pixie app (from Apple's additional tools for Xcode download) to verify the pixel layout of the window, so I can confirm that what Surface Info reported for the screen size is accurate.
Subsequent resizes of the window preserve this additional padding (thanks to window-step-resize = true). If I turn that off then I can manually resize the window to remove the additional padding, so it's just an error in the initial viewport sizing.
I do note that this is effectively adding twice as much padding as it should. With window-padding-x = 1 it should have a total of 2pt of padding but it has 4pt. With window-padding-x = 2 it should have a total of 4pt of padding but it has 8pt. I am wondering if this is an issue with high-DPI screens where it does an extra pixel density multiplication somewhere (e.g. it calculates 4pt, converts to 8px, then interprets that as 8pt) but I don't have a low-DPI screen available to test with.
I am wondering if this is an issue with high-DPI screens where it does an extra pixel density multiplication somewhere (e.g. it calculates 4pt, converts to 8px, then interprets that as 8pt) but I don't have a low-DPI screen available to test with.
I'm almost certain this is the case.
I'm not seeing this on my macOS build with high DPI screen. I'm seeing exactly the pixels it's noting. Is there a configuration I'm missing? I tried both a Pro Display XDR and MacBook Pro built-in display.
I moved my config aside and tried again and I'm seeing the same issue, an extra 8px. Completely out-of-the-box settings:
| Dimensions | Value |
|---|---|
| Screen Size | 1600px × 570px |
| Grid Size | 99c × 16r |
| Cell Size | 16px × 35px |
| Window Padding | T=4 B=4 L=4 R=4 |
| Font Size (Points)[^1] | 0 pt |
| Font Size (Pixels) | 26 px |
My main screen is an external LG UltraFine with a base resolution of 5120 × 2880, running at 2x DPI for a UI resolution of 2560 × 1440. If I convince Ghostty to open a window on the built-in screen it has the same metrics though. I also double-checked on my other laptop with no external screen and same problem there. This is macOS Sequoia 15.1 on Apple Silicon MBPs.
[^1]: This always reports 0 pt, I assume that's just a bug though.
I run into something similar on a MacBook Pro with the built-in 16-inch (3456 × 2234) display. The screen is on the default "looks like" setting of 1728 × 1117. I narrowed my problem down to just this config:
window-padding-y = 4
window-step-resize = true
Ghostty opens by default in 99c x 33r and has more padding at the bottom than what I'd expect. When I resize the window with the mouse from the bottom, the following happens:
| Size | Bottom padding | Notes |
|---|---|---|
| 99c x 33r | too much | Initial size |
| 99c x 34r | slightly more padding than 33r | |
| 99c x 35r | slightly more padding than 34r | |
| 99c x 36r | slightly more padding than 35r | |
| 99c x 37r | slightly more padding than 36r | |
| 99c x 38r | slightly more padding than 37r | |
| 99c x 39r skipped (!) | ||
| 99c x 40r | no padding at the bottom |
After that, the padding starts to slowly increase again.
I see the same issue, Macbook Pro with an external 4k screen (3840x2160), with window-padding-y=8 and window-step-resize=true; you can clearly see in the video when basically a whole empty line suddenly appears at the bottom of the terminal window:
https://github.com/user-attachments/assets/df8b2d1a-7b2f-48b7-9069-ce042e761acc
Even default config already triggers this issue for me. Initial window size is not exactly aligned to grid size in both axes. Changing the paddings will make the issue more or less obvious depending on padding values. Eg. window-padding-y = 3 is the most obvious for me (everything else default, Macbook Air M4 13").
As a side note the new rounded corners on Tahoe cut off part of the text with the default zero padding config.
