mirror of
https://github.com/wez/wezterm.git
synced 2024-12-18 02:42:05 +03:00
aee37784e5
The heart of this issue was that the resize callbacks have two layers of state; one in the low level window and one in the application level window. On Windows, the system triggers the low level callback prior to opengl being initialized. Since the application level depends on the opengl state, there are some code paths where it NOPs and returns early if opengl isn't yet initialized. When the system-wide display scaling is set to say 200%, the application layer can't know the effective DPI of the window it is creating because it doesn't know which monitor will be used or what its DPI will be. New windows are created at the default DPI of 96, and we rely on the resize events to detect the actual DPI and adjust the scaling in the window. The early call of the resize callback meant that the low level and application level size/dpi state was out of sync and the result was that the window had half as many pixels as it should, but that the terminal model was still sized as though it had the correct amount (twice as many as visible). This resulted in the window being too small for the viewport. The resolution is simple: we now suppress emitting the resize processing until opengl has been initialized. The test scenario for this is: * Set system scaling to 100% * Launch wezterm * Set system scaling to 200% * Observe that wezterm scales to match * Press CTRL-SHIFT-N to spawn a new window * Observe that the new window size matches the other window (previously this one would be half the size) While I was looking at this, I noticed that the manifest didn't match the DPI awareness that we have in the code, so update that. refs: https://github.com/wez/wezterm/issues/427 |
||
|---|---|---|
| .. | ||
| colors | ||
| fonts | ||
| icon | ||
| macos/WezTerm.app | ||
| shell-integration | ||
| windows | ||
| wezterm.appdata.xml | ||
| wezterm.desktop | ||