Initial dimensions on windows are not default and not configurable

[werkt]

What Operating System(s) are you seeing this problem on?

Windows

WezTerm version

20211208-072952-b262568f

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Launching wezterm on windows ignores initial_rows/cols. It starts with a square-ish window, with 53x15 dimensions and 886x800 pixels. With or without config, with or without setting those values in it, despite the docs indicating that 80x24 is the start dimensions, and that the implication of the configs is that they will affect the startup window.

To Reproduce

Start wezterm on windows.
The window will appear with the above dimensions and row/col counts

Configuration

no config

Expected Behavior

The default values of 80x24 should be applied without a config.
The modified values when supplied in a config file should be applied in those cases.

Logs

13:09:33.875 INFO wezterm_mux_server_impl::local >setting up C:\Users\ggensure.local/share/wezterm\gui-sock-37556
13:09:34.924 WARNING window::os::windows::window >EGL init failed Config says to avoid EGL, fall back to WGL
13:09:35.150 WARNING wezterm_term::terminalstate >unhandled DecPrivateMode SetDecPrivateMode(Unspecified(9001))
13:09:35.161 INFO wezterm_gui::termwindow > OpenGLinitialized! NVIDIA GeForce RTX 3090/PCIe/SSE2 4.5.0 NVIDIA 497.09 is_context_loss_possible=true wezterm version: 20211208-072952-b262568f

Anything else?

Initial window size with no config and some helpful counters. Last char omitted to not incur line feed.

[wez]

If I run wezterm -n (which runs with the default config), I do get an 80x24 window; I confirm that by running wsl and then echo $LINES $COLUMNS.

Are you perhaps running some kind of window manager-y thing that might tweak the window size?

You can debug by setting WEZTERM_LOG=wezterm_gui::termwindow::resize=trace,info in the environment and then launching wezterm.

It should log info about resizing to stderr; this is what I see:

 2021-12-08T18:58:58.508Z INFO  wezterm_mux_server_impl::local > setting up C:\Users\wez\.local/share/wezterm\gui-sock-5924
 2021-12-08T18:58:58.864Z WARN  window::os::windows::window    > EGL init failed Config says to avoid EGL, fall back to WGL
 2021-12-08T18:58:59.057Z WARN  wezterm_term::terminalstate    > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(9001))
 2021-12-08T18:58:59.064Z INFO  wezterm_gui::termwindow        > OpenGL initialized! NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 4.5.0 NVIDIA 466.77 is_context_loss_possible=true wezterm version: 20211203-101400-78d4329c
 2021-12-08T18:58:59.070Z TRACE wezterm_gui::termwindow::resize > resize event, current cells: RowsAndCols { rows: 24, cols: 80 }, current dims: Dimensions { pixel_width: 820, pixel_height: 572, dpi: 96 }, new dims: Dimensions { pixel_width: 820, pixel_height: 572, dpi: 96 } window_state:(empty)
 2021-12-08T18:58:59.071Z TRACE wezterm_gui::termwindow::resize > dimensions didn't change NOP!

[werkt]

Got it. Problem is 125% scaling. Window size matches with the points for 80x24 with 100% scaling, but doesn't factor the os setting:

Definitely can't give up that scaling - can I convince you to incorporate the following in your app manifest? They've been lying to you this whole time.

https://stackoverflow.com/questions/33507031/detect-if-non-dpi-aware-application-has-been-scaled-virtualized/36864741#36864741

Log from below indicating that 96 is being presented by the OS, while 120 is what you should have been told.

 2021-12-09T03:43:55.520Z INFO  wezterm_mux_server_impl::local > setting up C:\Users\ggensure\.local/share/wezterm\gui-sock-3200
 2021-12-09T03:43:55.858Z WARN  window::os::windows::window    > EGL init failed Config says to avoid EGL, fall back to WGL
 2021-12-09T03:43:56.029Z WARN  wezterm_term::terminalstate    > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(9001))
 2021-12-09T03:43:56.034Z INFO  wezterm_gui::termwindow        > OpenGL initialized! NVIDIA GeForce RTX 3080/PCIe/SSE2 4.5.0 NVIDIA 496.49 is_contex
t_loss_possible=true wezterm version: 20211206-204602-0c4a3205
 2021-12-09T03:43:56.038Z TRACE wezterm_gui::termwindow::resize > resize event, current cells: RowsAndCols { rows: 24, cols: 80 }, current dims: Dim
ensions { pixel_width: 820, pixel_height: 572, dpi: 96 }, new dims: Dimensions { pixel_width: 820, pixel_height: 572, dpi: 144 } window_state:(empty
)
 2021-12-09T03:43:56.042Z TRACE wezterm_gui::termwindow::resize > apply_dimensions Dimensions { pixel_width: 820, pixel_height: 572, dpi: 144 } scal
e_changed_cells None. window_state (empty)
 2021-12-09T03:43:56.042Z TRACE wezterm_gui::termwindow::resize > apply_dimensions computed size PtySize { rows: 15, cols: 56, pixel_width: 784, pix
el_height: 480 }, dims Dimensions { pixel_width: 820, pixel_height: 572, dpi: 144 }

[wez]

Hmm, the manifest is set to per-monitor dpi awareness: https://github.com/wez/wezterm/blob/main/assets/windows/manifest.manifest

aee3778 was the last change that touched that code, and I recall changing scaling as part of testing that.

I think that 827adf3 or a similar more recent change regressed something with this.
Needs some more digging!

[wez]

This is fixed in the nightly build; give it about 40 minutes or so to build out for Windows and let me know how you get on!

[werkt]

Great job, looks good after nightly download. Feel free to close unless you want to wait for a stable.

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