mirror of
https://github.com/wez/wezterm.git
synced 2024-12-24 05:42:03 +03:00
A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
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 |
||
|---|---|---|
| .cargo | ||
| .github | ||
| assets | ||
| async_ossl | ||
| base91 | ||
| bintree | ||
| ci | ||
| codec | ||
| config | ||
| deps | ||
| docs | ||
| env-bootstrap | ||
| filedescriptor | ||
| licenses | ||
| luahelper | ||
| mux | ||
| promise | ||
| pty | ||
| rangeset | ||
| ratelim | ||
| strip-ansi-escapes | ||
| tabout | ||
| term | ||
| termwiz | ||
| test-data | ||
| tmux-cc | ||
| umask | ||
| vtparse | ||
| wezterm | ||
| wezterm-client | ||
| wezterm-font | ||
| wezterm-gui | ||
| wezterm-gui-subcommands | ||
| wezterm-input-types | ||
| wezterm-mux-server | ||
| wezterm-mux-server-impl | ||
| wezterm-toast-notification | ||
| window | ||
| .cirrus.yml | ||
| .gitignore | ||
| .gitmodules | ||
| .rustfmt.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| get-deps | ||
| LICENSE.md | ||
| README.md | ||
| wt-record | ||
| wt-replay | ||
Wez's Terminal
A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
User facing docs and guide at: https://wezfurlong.org/wezterm/
Screenshot of wezterm on macOS, running vim
Installation
https://wezfurlong.org/wezterm/installation.html
Getting help
This is a spare time project, so please bear with me. There are a couple of channels for support:
- You can use the GitHub issue tracker to see if someone else has a similar issue, or to file a new one: https://github.com/wez/wezterm/issues
- Start or join a thread in our GitHub Discussions; if you have general questions or want to chat with other wezterm users, you're welcome here!
- There is a Matrix room via Element.io for (potentially!) real time discussions; that is bridged from the original Gitter room that has some longer term users and older discussions.
The GitHub Discussions and Element/Gitter rooms are better suited to questions than it is to bug reports, but don't be afraid to use whichever you are most comfortable using and we'll work it out.