-
-
Notifications
You must be signed in to change notification settings - Fork 811
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow, animated text selection #33
Comments
Non-related question: is mouse support on the road? conhost supports it, but the new microsoft/terminal doesn't. |
Thanks for reporting this. I'll take a look: I did some work to improve this reasonably recently in
That's an unfortunate limitation in conpty; it affects everything that uses conpty. Here's the issue I filed with Microsoft: Since it seems like it will have a long time frame to resolve in conpty, what are the interim solutions? winptyI moved the instructions for this from here to: #35 wezterm multiplexingThis is very new code with very light testing, but the idea is that you can connect to the WSL environment from the win32 gui environment using the multiplexer/terminal server protocol in wezterm. You will have a wezterm running as a server in your WSL environment and a win32 wezterm running as the native gui. In your WSL environment:
In your win32 environment
New windows and tabs will spawn new processes in the WSL environment, but render natively in the gui. The performance of this is not as good as it could be, and this area is under active development so it should improve reasonably rapidly over the next couple of weeks. |
Back to the selection performance: I just tried this and it works very snappy on the system I have handy, which is a pretty powerful work laptop: Razer blade with a good GPU. Can you share some details about the system you're running on (CPU, GPU, screen resolution, the approximate size of the wezterm window)? I'd like to understand whether this might be related to the available power in the system or whether something else might be a factor so that I can figure out how to reproduce and then resolve this issue. You are not the only person to mention the selection performance: @xavierd also brought it up to me the other day. |
When using WSL, we want to place the unix socket on NTFS and that reports an insecure set of permissions which cause us to refuse to start up. As a bit of a gross hack, allow skipping that check by setting an environmental variable: ``` WEZTERM_SKIP_MUX_SOCK_PERMISSIONS_CHECK= wezterm start --front-end muxserver ``` that works best in conjunction with this in the WSL `.wezterm.toml` file: (swap `wez` with your username): ``` mux_server_unix_domain_socket_path = "/mnt/c/Users/wez/.local/share/wezterm/sock" ``` refs: #33
(I just tested the wezterm multiplexing stuff on win32 and edit my comment with instructions: it works with the mouse but feels a little sluggish when initially opening the window) |
Please also tell me whether you are using a build you downloaded from our releases section (if so, which one you downloaded), or whether you built it for yourself (if so, which revision of the repo, and can you confirm that you built with the In addition, do you have any non-default configuration in your |
This do_paint call was added in 8995974 but I don't think it was intentional; it looks like an accidental commit of something during debugging. The intent is that we tick over and paint every tick (~50ms) and this behavior here was causing us to paint after every input event, which is undesirable when processing the selection. refs: #33
The closest I got to reproducing this was with a debug build, which was only occasionally sluggish for large selections. I did spot and remove what appeared to be some debug code that got left in (7471774), and with that removed I couldn't get it to feel slow, so maybe this will fix it for you? I'd suggest waiting for that build to show up on appveyor and trying it out. |
Rebuilding wezterm on top-of-tree did the trick for me :) |
Thank you for the reply! We could close this issue, as the slow selection is fixed, right?
|
Yep, that looks much better! I'll close this out, thanks for reporting this! |
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. |
Is it a build problem?
No
Did something not work the way you expected?
Selecting text with the mouse seems to have a slow animation applied instead of being instant.
Running on Windows 10 Pro
What did you try?
What did you expect to happen?
Instant text selection
What actually happened?
Slow and animated text selection
The text was updated successfully, but these errors were encountered: