window-step-resize using wrong step sizes on macOS

[roblillack]

Step resizing is broken for me as it feels like the size increments are out of sync with the font size, leading to a seeminly random padding on the bottom and the right side of the window.

Here's a video highlighting the behavior:

2024-12-31.ghostty-resizing-broken-vertical.mov

And another one with the inspector open:

2024-12-31.ghostty-resizing-broken-inspector.mov

I'm on a MacBook Pro 14" and seeing this on the internal screen with "standard scaling" and my font of choice is JetBrains Mono.

These are the things that don't make a difference:

• disabling the window padding
• changing the font
• changing the font size
• changing the system's display scale factor (even completely disabling retina mode by using the displays native resolution)

The resize increments always seem to be way off compared to the font size (ie. font size: 26px --> vertical step size: 18px, font size: 24px --> vertical step size: 16px).

[roblillack]

Playing around with this a bit more, it seems like some font family/size combinations seem to work correctly, though:

• Courier New/13pt works, with 12.5pt it seem to be broken only vertically and with 12pt it is broken horizontally as well
• Menlo/12.5pt works, Menlo/13pt is broken
• PT Mono 13pt works, PT Mono/12.5pt is broken

Additionally, in cases where it does work, the initial window size sometimes is off even if the increments are correct, when a window padding != 0 is specified:

2024-12-31.ghostty-border-padding.mov

[JakeWharton]

Same as #2946? I feel your pain!

[roblillack]

Yes, I think #2946 and the last part of the reported issue (wrong initial window size) look to be the same as #2664. Regarding the broken, font dependent resize increments. 🤷

[ilyagr]

I'm experiencing something similar. It is somewhat reminiscent of #2664, but not identical. I tested this on Ghostty 1.0.0 on Mac OS Sonoma on ARM, with the config consisting just of

window-step-resize=true

On start, the window is not perfectly aligned, but OK:

One problem happens on resizing:

Video:

480.2024-12-29.at.12.16.15.AM.mov

Another problem is that resizing with Cmd-= keeps the window size the same, so even if it was divisible by the size of a character cell before, it isn't after.

In #2664 (I think) someone mentioned that this could be related to High-DPI displays, and indeed I have somewhat unusual monitor setup. I'm using these BetterDisplay settings on an external 1440x2560 display (rotated vertically, in extended desktop mode). Note the HiDPI.

P.S. This is not a huge problem for me, I switched to using window-padding-color=extend-always and window-step-resize=false, which works out OK for me. The first of these is a great idea, haven't seen it in other terminals.

[mitchellh]

I think this discussion may be exactly this comment: #2946 (comment)

Certain font sizes force cell sizes that could result in fractional size increments which macOS doesn't support, perhaps. I haven't verified this, but it sounds plausible.