Better Font DPI guestimation on Linux

[jasmith79]

WezTerm, current AppImage (20210203-095643-70a364eb), running under Linux X11 (Cinnamon DE) on a 4k screen (HP Z book, 3840 x 2160) has unreadably tiny font.

To Reproduce

Install wezterm, add executable flag, run.

Expected behavior

Default font DPI should be readable.

Doing a quick grep through the code looks like you have special handling for MacOS (assumes Retina?) but not for any other system that may have a high-density display. Even on my 2020 MacBook Air the default font is pretty tiny for my (admittedly aging) eyes.

I took a quick look at implementing a cross-platform DPI calculation... and I think I quickly realized why you haven't done that. X is reporting my laptop screen as being over 2 meters wide, just to name one problem. I'm assuming that when I set the scaling in Cinnamon rather than doing something sensible it just multiplied the dimensions of my 15" screen?

That being said, a quick sanity check like (psuedocode) if display_pixels_width > 3000 to set the DPI to a more reasonable 192 or something would give a better first run experience on Linux with 4k since there doesn't seem to be a better way to get a scaling factor. Alternatively, you could add a note to the docs to mention setting the DPI to a higher value on 4k monitor screens, they aren't that uncommon anymore. I apologize that my Rust-fu is probably not up to pull request standards, but I'd be happy to add a blurb to the docs if you'd like.

This is perhaps the most full-featured terminal emulator I've found on Linux and might just finally be the iTerm2 replacement I've been looking for. Thanks for creating this!

[wez]

DPI is surprisingly difficult :-/

macOS actively does not want you to think about pixels and there are no APIs for determining the actual DPI. Instead, it uses a fixed DPI of 72 as a base, and sets a scaling factor of 2 for a Retina display. Wezterm should adjust to this automatically; dragging a window from the laptop to an external display should cause the scaling to adjust accordingly.

WezTerm's default font size of 10pts results in a window that looks the same size and with text the same size as in Terminal.app set to the same font at 10pt, so I don't think there is a DPI issue there. Just that the default font size could perhaps be larger?

On Windows, the OS tells us the true DPI for the window, and we detect scaling changes when moving between monitors.

Wayland is similar to macOS in that it doesn't want to report the DPI, but will report a scaling factor to the rendering code.

X11 is the weakest of the bunch: getting the true DPI seems difficult; last time I looked, the reported physical dimensions of the monitor were non-sensical, and there is an X resource that is often (but not always!) used to override the dpi for applications.

The docs as they are now don't do a good job of explaining DPI concerns, so it's fair to call that out for improvement.

I'm definitely interested in making Linux DPI defaults better, I just don't know specifically what better looks like in practice.

Regarding guessing based on resolution: I use an ultrawide monitor with 5120 horizontal pixels. That isn't high dpi, so the simple resolution based heuristic would leave me with the wrong dpi.

[jasmith79]

That's totally fair, and a good counterpoint to the resolution guessing heuristic.

I'll submit a pull request tomorrow for the documentation with a blurb about text scaling unless you want to do it.

[wez]

I'd welcome your contribution for this; while I could write something up, I think seeing how you phrase the changes you'd like to see in the docs will help me see where they are deficient and help cover where I might potentially have a blind spot or other assumptions.

[wez]

Can you share what this outputs on your system?

xprop -root | grep dpi

[jasmith79]

RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.dpi:\t192\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.rgba:\trgb\n"

I note that the Xft.dpi value in there is 192, which is what I have the dpi set to in my wezterm config.

[wez]

OK, I can teach wezterm to read that value and use that for the dpi if unspecified on linux.

[jasmith79]

Sounds good, thank you.

[wez]

The current nightly builds should be better at this now; would you mind giving it a try and reporting back?

[jasmith79]

Ok, moved my config, downloaded the nightly app image, and it does have the correct DPI out of the box.

However, there is now a weird visual glitch: I have a greeting printed out when fish shell loads. With the stable it prints out correctly, with the nightly it will either add a non-interactive prompt over top of it cutting off the last few words of text or sometimes it will flash on the screen but then vanish, like I'd run clear. Not the end of the world, but thought I'd mention it in case it was indicative of a regression or a deeper issue.

I'm using fish 3.1.0 with the spacefish prompt and a lot of plugins including git, vi keybindings, etc.

[wez]

Good to hear that the DPI situation is better!

Please open a separate issue for the visual glitch; I think it will be useful to capture a session recording; there's some information on doing that here: https://github.com/wez/wezterm/blob/main/.github/ISSUE_TEMPLATE/bug_report.md#session-recording

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.