Font rendering oddities on external display, custom dpi setting, etc.?

[jesseleite]

Firstly, thank you so much @wez for all you do on WezTerm! I've been absolutely loving it! 🔥

Anyway, I'm noticing some weird font rendering oddities on my external LG display. For example...

These kinds of rendering oddities seem totally random, and I don't think they happen at all on my Mac's Retina display, but they happen quite often on my external LG display.

Maybe Wezterm's dpi setting is wrong for my LG display's physical ppi? The dpi docs page says that on macOS, the display cannot be probed, so WezTerm decides between 72 and 144 dpi based on whether it detects the internal retina display or not. My LG display is a physical 109 ppi, so I thought I'd try setting an explicit dpi = 109 to see if that produces more stable font rendering...

local wezterm = require('wezterm')

local config = {
  term = "wezterm",
  font = wezterm.font('JetBrains Mono'),
  font_size = 16.5,
  line_height = 1.6,
  -- etc...
}

if wezterm.gui.screens().active.name == 'LG HDR WQHD' then
  config.dpi = 109
  config.font_size = 11
end

return config

I guess I have two questions regarding all of this...

1. Though I'm not sure yet if this fixes my font issues, the above config seems to work as far as detecting my LG display when starting Wezterm 👍 However, when I manually save my config and the hot reload happens, I get this error...

   

   ...Is there a way to suppress this error when hot reloading the config?

2. Has anyone else seen these kinds of font rendering oddities and/or know what may be causing them?

[nekowinston]

Regarding 1), you'd have to use events & callbacks to do this during runtime, not when loading the config, e.g.

local wezterm = require("wezterm")

wezterm.on("update-status", function(window, pane)
  if wezterm.gui.screens().active.name == "LG HDR WQHD" then
    window:set_config_overrides({ dpi = 109 })
  else
    -- reset
    window:set_config_overrides({ dpi = 144 })
  end
end)

I've tested this on macOS, and I don't think you can actually change dpi settings during runtime? Changing font_size works without issues.

[jesseleite]

Indeed, dpi changes don't take effect during runtime, but now I'm curious why it couldn't take effect during a hot reload? Would be awesome 🙏

At least for the moment, I guess I need to do this check before the gui creates my window, rather than within a later event after the window is created. All that said, my above config example does still work when first booting WezTerm, aside from the error during hot reload 🤔

[nekowinston]

hot reloading still behaves like changes at runtime for any behavior i can think of. Things like window decorations also cannot be changed with hot reload nor during runtime, but only on a restart.

[jesseleite]

Yep I hear you 👍 ...I can't set dpi in an event like update-status for that very reason.

I thought of hooking into the gui-startup event since that one seems to fire before window creation, but I can't see to figure out how to spawn_window() with a custom dpi (since it doesn't take standard config options).

[shiomiyan]

Probably have similar issue. I'm using Windows and LG 34WQ75C-B. The height at which the fonts are rendered is disjointed.

I don't know the details, but I reproduce this problem when I set line_height.

I have not tried many, but when I set Consolas as the font, it does not reproduce.

Minimal Config file below.

local wezterm = require("wezterm")

local config = {
	font = wezterm.font("JetBrains Mono"),
	font_size = 13,
	line_height = 1.2,
}

return config

[jesseleite]

Ha! That screenshot example is quite bad! It happens with JetBrains Mono as well, but not quite that bad. Almost positive this is dpi related, since you're on external monitor with a non-standard dpi/ppi spec like I am.

It looks like that specific monitor's ppi is 110. Curious if your problems go away if you set dpi = 110 in your config and reboot WezTerm? Font scaling with custom dpi settings can be kinda whacky at the moment, but it's worth trying to see if the disjointed looking rendering issues go away.

[shiomiyan]

Minimal Config file below.

Sorry for my mistake, the screenshot was JetBrains Mono, but the config that I pasted above incorrectly stated Consolas.

Curious if your problems go away if you set dpi = 110 in your config and reboot WezTerm?

Umm... It does not seem to be resolved.

Wezterm document says "Probed from the display" on Windows.
I'm not familiar with it, but maybe this method is not appropriate in my environment... 🤔

[Huliiiiii]

Also on Windows. This issue might be related to system scaling. Change dpi in settings to match the physical DPI of the monitor or change system scaling to 100% can fix font rendering.

[wez]

I'd suggest disabling hinting to see if that looks better:

config.freetype_load_flags = 'NO_HINTING'

[Arinono]

I recently started moving away from iterm2 and firstly, I'd like to say thank you, it was very fast and effortless with great results!

I had a similar issues to others above, but much more subtle:
(I forgot to put it in the screenshots since I don't have any decoration it's not obvious: left is wezterm, right it iterm2)

not setting `NO_HINTING`

This fixed part of my issue:

with `NO_HINTING`

Now the 2 is properly sized, but the `d` in italic still is "missing" part of it. It's not really missing, just very blurry when you zoom in (anti-aliasing ?)

With a lot of zoom, it looks like this:
it's crisp, but the d is chopped off

huge zoom

config (it's still very minimal, but it was what I only needed to match item2)

local wezterm = require("wezterm")

local config = wezterm.config_builder()

config.automatically_reload_config = true
config.quit_when_all_windows_are_closed = true

config.color_scheme = "tokyonight_storm"
config.font_size = 14
config.freetype_load_flags = "NO_HINTING"
config.font = wezterm.font_with_fallback({
	{ family = "Dank Mono", weight = "Bold" },
	{ family = "MesloLGL Nerd Font", weight = "Bold" },
})

config.enable_tab_bar = false
config.window_decorations = "RESIZE"
config.window_padding = {
	left = 0,
	right = 0,
	top = 0,
	bottom = 0,
}

return config

edit: Also on an external display, hence why I write here, but not a hDPI one (just 1920x1080), not that it matters, the result is exactly the same on the UHD one