Gray border on certain window sizes with a color scheme applied

[varchaar]

Describe the bug

I'm not sure if it's a bug or a config error from me but I have a gray border on the right and the bottom of the window but only with a custom theme and on some window sizes, it's like a margin. If it's an expected behavior, is it possible to set the color of this "padding" to the background color ?

Environment (please complete the following information):

• OS: MacOS 11.2.3
• Version: wezterm 20210405-110924-a5bb5be8

To Reproduce

just launch wezterm with and without colorscheme and resize the window, with a colorscheme a gray border appear, without one none.

Configuration

local wezterm = require 'wezterm';

wezterm.on("update-right-status", function(window, pane)
  -- "Wed Mar 3 08:14"
  local date = wezterm.strftime("%a %b %-d %H:%M ");

  local test = wezterm.run_child_process({"whoami"});
  local bat = ""
  for _, b in ipairs(wezterm.battery_info()) do
    bat = " " .. string.format("%.0f%%", b.state_of_charge * 100)
  end

  window:set_right_status(wezterm.format({
    {Text=bat .. "   "..date},
  }));
end)

return {
  color_scheme = "ayu", -- This part is commented on the first screenshot
  window_close_confirmation = "NeverPrompt",
  font = wezterm.font("FiraCode Nerd Font"),
  font_size = 13.0,
  font_shaper = "Allsorts",
  -- freetype_load_target = "Light",
  harfbuzz_features = {"calt=1", "clig=1", "liga=1"},
  allow_square_glyphs_to_overflow_width = "Never",
  keys = {
    -- This will create a new split and run the `top` program inside it
    {key="d", mods="CMD", action=wezterm.action{SplitHorizontal={domain="CurrentPaneDomain"
    }}},
    {key="d", mods="CMD|SHIFT", action=wezterm.action{SplitVertical={domain="CurrentPaneDomain"
    }}},
    {key="w", mods="CMD",
     action=wezterm.action{CloseCurrentPane={confirm=false}}},
    { key = "h", mods="CMD",
      action=wezterm.action{ActivatePaneDirection="Left"}},
    { key = "l", mods="CMD",
      action=wezterm.action{ActivatePaneDirection="Right"}},
    { key = "j", mods="CMD",
      action=wezterm.action{ActivatePaneDirection="Up"}},
    { key = "k", mods="CMD",
      action=wezterm.action{ActivatePaneDirection="Down"}},
   }
 }

Expected behavior

The best solution, I think is to have the background color instead.

Screenshots

[wez]

Seems similar to https://github.com/wez/wezterm/issues/589 which hasn't been root caused yet

[varchaar]

It seems so, you´re right, sorry for the duplicate.

[wez]

It seems so, you´re right, sorry for the duplicate.

No worries; I'm hoping to find a way to reproduce it, and I was hoping that the color scheme was a key part of it, but I still can't reproduce this on my M1 mac :-/

If you run wezterm from inside wezterm, it should print a line like this:

INFO  wezterm_gui::termwindow        > OpenGL initialized! Apple M1 4.1 Metal - 71.0.7 is_context_loss_possible=false wezterm version: 20210314-114017-04b7cedd-137-g298e0b8d

Can you share what it prints for you?

[varchaar]

Yes here is the output:

~
❯ wezterm
 2021-04-07T15:17:58.082Z INFO  wezterm_mux_server_impl::local > setting up /Users/varchar/.local/share/wezterm/gui-sock-1731
 2021-04-07T15:17:58.143Z WARN  wezterm_font::shaper::allsorts > Failed to parse
Memory { name: "../../assets/fonts/LastResortHE-Regular.ttf", data_len: 502504, index: 0 }: unexpected data version
 2021-04-07T15:17:58.204Z INFO  wezterm_gui::termwindow        > OpenGL initialized! Intel(R) Iris(TM) Plus Graphics 655 4.1 INTEL-16.1.12 is_context_loss_possible=false wezterm version: 20210405-110924-a5bb5be8
 2021-04-07T15:17:58.213Z WARN  wezterm_font::shaper::allsorts > Failed to parse
Memory { name: "../../assets/fonts/LastResortHE-Regular.ttf", data_len: 502504, index: 0 }: unexpected data version
 2021-04-07T15:17:58.414Z WARN  wezterm_font::shaper::allsorts > Failed to parse
Memory { name: "../../assets/fonts/LastResortHE-Regular.ttf", data_len: 502504, index: 0 }: unexpected data version

[rrpolanco]

Can also confirm this is happening to me on wezterm 20210405-110924-a5bb5be8-84-g2e34f1a8 running macOS 10.15.7 with Gruvbox Dark color scheme applied.

[gaydenko]

MBP running Big Sur 11.3.1 is affected the same way.

[wez]

MBP running Big Sur 11.3.1 is affected the same way.

@gaydenko Could you also share what you see if you do this: https://github.com/wez/wezterm/issues/653#issuecomment-814541780

[gaydenko]

Here it is:

~ wezterm
 2021-05-08T17:01:32.762Z INFO  wezterm_mux_server_impl::local > setting up /Users/user/.local/share/wezterm/gui-sock-30103
 2021-05-08T17:01:32.861Z INFO  wezterm_gui::termwindow        > OpenGL initialized! Intel(R) UHD Graphics 630 4.1 INTEL-16.2.16 is_context_loss_possible=false wezterm version: 20210502-154244-3f7122cb

[wez]

OK, so far it seems like this correlates with intel based macs.

[maddiemort]

This is also happening for me.

wezterm_gui::termwindow        > OpenGL initialized! AMD Radeon Pro 5500M OpenGL Engine 4.1 ATI-3.10.19 is_context_loss_possible=false wezterm version: 20210502-154244-3f7122cb

[gaydenko]

That is the issue is not Intel graphics related, isn't it?

[hovsater]

I'm seeing the same behaviour using the following configuration on macOS, 11.3.1, running on x86 architecture using Intel UHD Graphics 630 1536 MB.

WezTerm configuration

```lua local wezterm = require 'wezterm'; return { disable_default_key_bindings = true, -- Does not currently work. TODO: Fix upstream? -- skip_close_confirmation_for_processes_named = {}, font_size = 14, color_scheme = "Tomorrow Night", leader = {key="a", mods="CTRL", timeout_milliseconds=1000}, keys = { {key="1", mods="LEADER", action=wezterm.action{ActivateTab=0}}, {key="2", mods="LEADER", action=wezterm.action{ActivateTab=1}}, {key="3", mods="LEADER", action=wezterm.action{ActivateTab=2}}, {key="4", mods="LEADER", action=wezterm.action{ActivateTab=3}}, {key="5", mods="LEADER", action=wezterm.action{ActivateTab=4}}, {key="6", mods="LEADER", action=wezterm.action{ActivateTab=5}}, {key="7", mods="LEADER", action=wezterm.action{ActivateTab=6}}, {key="8", mods="LEADER", action=wezterm.action{ActivateTab=7}}, {key="c", mods="LEADER", action=wezterm.action{SpawnTab="CurrentPaneDomain"}}, {key="&", mods="LEADER|SHIFT", action=wezterm.action{CloseCurrentTab={confirm=true}}}, {key="x", mods="LEADER", action=wezterm.action{CloseCurrentPane={confirm=true}}}, {key="-", mods="LEADER", action=wezterm.action{SplitVertical={domain="CurrentPaneDomain"}}}, {key="|", mods="LEADER|SHIFT", action=wezterm.action{SplitHorizontal={domain="CurrentPaneDomain"}}}, {key="z", mods="LEADER", action="TogglePaneZoomState" }, {key="r", mods="CMD", action="ReloadConfiguration"}, {key="q", mods="CMD", action="QuitApplication"}, } } ```

wezterm output

```console ~ $ wezterm 2021-06-09T10:40:12.097Z INFO wezterm_mux_server_impl::local > setting up /Users/kevinsjoberg/.local/share/wezterm/gui-sock-82785 2021-06-09T10:40:12.222Z INFO wezterm_gui::termwindow > OpenGL initialized! AMD Radeon Pro 555X OpenGL Engine 4.1 ATI-4.4.17 is_context_loss_possible=false wezterm version: 20210502-154244-3f7122cb ```

[JeanMertz]

If it helps:

Today I noticed in addition to the colour difference showing up when the window isn't exactly equal to a multiple of cell dimensions, it also shows up when applying window padding (in this case, it doesn't matter what the padding is, 10 or 100, it'll fill the space with the same (incorrect) colour:

window_padding = {left = 100},

[wez]

I made a change that might help with this in the most recent commit; should be available as a nightly build download in ~30 minutes.

[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.