cmd line gets out of viewport when system display scaling is in use on Windows

[karschdn]

Describe the bug

After opening wezterm I get a cmd line. Then I start writing down commands. As soon as the cmd line runs out of the lower boundary of the window, the view does not scroll to the position to see it again.

Only after resizing the window it scrolls to the right position.

Very strange for me. Hopefully it is the same on your side. Wezterm fits to my visual requirements and I would love to use it. But it is not possible with this bug. I have no time to resize every cmd window after creating it :)

Environment:

• OS: Windows 10 pro 1809
• Version: wezterm 20201101-103216-403d002d-237-g42b95cd4

To Reproduce

• download nightly build for windows (also reproducable with latest stable)
• unpack zip
• open unpacked folder in explorer
• double click on "wezterm.exe"
• press enter until to cmd line runs out of focus (do not resize window before)
• as soon as you resize the window the view jumps to the last cmd line and everything is fine from now on

Configuration

Removing config does not help, but here it is...

return {
	window_background_image = "C:/media/desktop_16-9.jpg",
	initial_rows = 70,
	initial_cols = 300, 
	window_close_confirmation = "NeverPrompt",
	window_background_opacity = 0.7,
	window_background_image_hsb = {
	  brightness = 0.7,
  
	  -- You can adjust the hue by scaling its value.
	  -- a multiplier of 1.0 leaves the value unchanged.
	  hue = 1.0,
  
	  -- You can adjust the saturation also.
	  saturation = 1.0,
	}
	
  }

Expected behavior

When pressing enter, the view should scroll down to the last line (like it is done if I have resized the window one time)

Screenshots

[karschdn]

Nobody else have this problem? http://www.southbaypc.com/autosizer/ helps here to force a resize but it is still ugly because it needs to be triggered.

[wez]

Hmm, I'm not sure if we're capturing the repro steps because I don't see this behavior.
Here's what I'm trying:

• Run wezterm.exe -n this starts wezterm with the default configuration, as though there was no local config
• The gui starts and the window is sized so that exactly 24 rows * pixel height of the font are present in the client area
• hitting enter ~24 times to make the text scroll always has the cursor on the bottom line, and there are no partial lines.

From your screenshot, there are at least 32 rows in your terminal, and the partial row at the bottom leads me to believe that the window has been resized.

If I make my window taller and deliberately size it so that there is a partial row at the bottom, I see a blank space like this:

Is there something about your setup or environment that wasn't captured in the issue description?

[karschdn]

hmmm, i played around with my display settings. When putting the scaling to 100% the problem is not there. Due to hardware (native monitor resolution, display size, 4K, ... age of the person in front of the monitor :) ) I have to set it to 200% and then starting with -n looks like this and my problem occurs:

(ahm, after reviewing my screenshot I have to say that it looks too big :) I am not that handicaped :) )

[wez]

age of the person in front of the monitor :)

Heh, I've recently started to hold books at arms length to read and my font sizes on screen have gone up a couple of points :-p
I've avoided 4K displays because I don't find that they have very much space once you've doubled the font sizes to be able to read anything again :)
I've found that I really love ultrawide monitors for the extra screen real estate. I'm not mentioning this as a pre-requisite for using wezterm so much as just a generally recommendation!

i have to set it to 200% and then it looks like this and my problem occurs:

Thanks; I'll look at this with a different system display scaling when I'm next in front of my windows computer! It sounds like wezterm may need to take that into account when it computes the effective dpi of the screen.

With that in mind, you may wish to try playing with configuring the dpi in your config explicitly as a workaround. I would guess that you either need to set it to half or double the default value of 96.0. I'm guessing half is probably right to compensate for the whole screen scaling:

return {
   dpi = 48.0, -- or 192.0
}

You may then need to increase the font_size to get to your preferred readable size.

(ahm, after reviewing my screenshot I have to say that it looks to big :) I am not that handicaped :) )

No judgements here: you need to look after your eyes!

[karschdn]

Thanks for your hints !

192 dpi does the job for me. Even without font size changes. So, fix could be something like newdpi=default dpi * windows scaling. (I am only guessing :) )

return {
   dpi = 192.0
}

( sounds like the difference of our ages is not that high :) )

[wez]

Thanks for playing with the dpi and confirming that theory!

I've pushed a commit that resolves this; it should show up in the nightly builds within an hour or two. If you're interested in the gory details and the simple fix, you can read the commit message: aee3778

Once you're on that build, you can (and should, especially if you have multiple monitors with varying dpi!) remove the dpi setting from your config.

[karschdn]

Nightly build works for me! Thank you very much for fixing it!

Well managed product (docu, change process, response time, ... )

[github-actions]

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.