Skip to content
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

Closed
zurp opened this issue Jun 12, 2019 · 10 comments
Closed

Slow, animated text selection #33

zurp opened this issue Jun 12, 2019 · 10 comments

Comments

@zurp
Copy link

zurp commented Jun 12, 2019

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

wezterm

@zurp
Copy link
Author

zurp commented Jun 12, 2019

Non-related question: is mouse support on the road?

conhost supports it, but the new microsoft/terminal doesn't.
is it possible to add?

@wez
Copy link
Owner

wez commented Jun 12, 2019

Thanks for reporting this. I'll take a look: I did some work to improve this reasonably recently in
c207142 but it sounds like something else it going on so I'll dig deeper.

Non-related question: is mouse support on the road?

conhost supports it, but the new microsoft/terminal doesn't.
is it possible to add?

That's an unfortunate limitation in conpty; it affects everything that uses conpty. Here's the issue I filed with Microsoft:
microsoft/terminal#376

Since it seems like it will have a long time frame to resolve in conpty, what are the interim solutions?
There are two possibilities you can try now, but neither are currently well tested--my main platforms at the moment are posix, so I haven't been forced to polish the windows side. I would value your feedback on how well these work for you.

winpty

I moved the instructions for this from here to: #35
I couldn't get the mouse reporting to work with this when I tried just now with msys.

wezterm multiplexing

This 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:

  • build the master branch of wezterm (you need b31e9ec or later)
  • in the ~/.wezterm.toml set mux_server_unix_domain_socket_path = "/mnt/c/Users/USERNAME/.local/share/wezterm/sock. The important thing is that this path be something resolvable from the win32 environment (eg: somewhere on /mnt/c/). This particular path maps to the default used on the win32 side.
  • run WEZTERM_SKIP_MUX_SOCK_PERMISSIONS_CHECK=1 wezterm start --front-end muxserver

In your win32 environment

  • Grab a build from master: https://ci.appveyor.com/project/wez/wezterm/build/artifacts?branch=master
  • In your win32 ~/.wezterm.toml, set mux_server_unix_domain_socket_path to the win32 version of the path you set in the WSL environment (mux_server_unix_domain_socket_path = "/mnt/c/Users/USERNAME/.local/share/wezterm/sock")
  • run wezterm start --broken-mux-client-as-default-domain

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.

@wez
Copy link
Owner

wez commented Jun 12, 2019

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.

wez added a commit that referenced this issue Jun 12, 2019
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
@wez
Copy link
Owner

wez commented Jun 12, 2019

(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)

@wez
Copy link
Owner

wez commented Jun 12, 2019

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 --release flag)?

In addition, do you have any non-default configuration in your wezterm.toml file? The scrollback_lines setting can influence the worst case complexity of selection processing so I'm wondering about that value in particular.

wez added a commit that referenced this issue Jun 12, 2019
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
@wez
Copy link
Owner

wez commented Jun 12, 2019

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.

@xavierd
Copy link

xavierd commented Jun 13, 2019

Rebuilding wezterm on top-of-tree did the trick for me :)

@zurp
Copy link
Author

zurp commented Jun 13, 2019

Thank you for the reply!
Just got the latest build (01a8c32), it's much faster.
I have no wezterm.toml (yet).
The capture at the bottom is at ~30fps.

We could close this issue, as the slow selection is fixed, right?

Can you share some details about the system you're running on (CPU, GPU, screen resolution, the approximate size of the wezterm window)?
CPU: Intel i7-8700K (12) @ 3.696GHz
GPU: NVIDIA GeForce GTX 1070
Resolution: 2560 x 1440 @ 144hz
Window size: 1306 x 640

wezterm2

@wez
Copy link
Owner

wez commented Jun 13, 2019

Yep, that looks much better! I'll close this out, thanks for reporting this!

@wez wez closed this as completed Jun 13, 2019
@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants