-
-
Notifications
You must be signed in to change notification settings - Fork 756
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
resizing in mux domains has issues #5142
Comments
I have the same issue. The problem is much more pronounced if there is a lot of text in the pane. And sometimes the panes will keep dancing around even after I let go of them, and will only stop after I have detached then re-attached the domain. |
actually, it doesn't take that much, mostly empty panes will struggle too. here is a video showing off this behavior, it's a bit long. at the start you will notice resizing was extremely slow even for empty panes, then several seconds after I have let go, the panes started to dance around. the experience is really bad, basically wezterm isn't a viable tmux replacement because of this. bug.mp4 |
I see now that there are actually 2 different problems here. One being that pane resizing is extremely slow. With some profiling I found out one hotspot is The second being the panes jumping around. This is exacerbated by the first problem, but even after I commented out the call to |
I have noticed that the |
I think there is a feedback loop in |
Yes, so |
say the pane with 100 cols wide, we got 3 mouse events, one move the split to 99, the next one move it to 98, then to 90 we would first call resize_split_by with -1, -1, then with -8. the first resize is completed just as we call resize_split_by(-8), this triggers a resync, and updates the split position to 99. because of that resize_split_by(-8) will try to resize it to 91, instead of the desire 90. in practice, there are a lot more mouse events and the timing is more unpredictable, the end result can be very chaotic. partially fix wez#5142
say the pane with 100 cols wide, we got 3 mouse events, one move the split to 99, the next one move it to 98, then to 90 we would first call resize_split_by with -1, -1, then with -8. the first resize is completed just as we call resize_split_by(-8), this triggers a resync, and updates the split position to 99. because of that resize_split_by(-8) will try to resize it to 91, instead of the desire 90. in practice, there are a lot more mouse events and the timing is more unpredictable, the end result can be very chaotic. partially fix wez#5142
What Operating System(s) are you seeing this problem on?
Linux X11, macOS
Which Wayland compositor or X11 Window manager(s) are you using?
No response
WezTerm version
wezterm 20240102-011725-2f7ca41a
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
No, and I'll explain why below
Describe the bug
To Reproduce
Configuration
no config
Expected Behavior
No response
Logs
Anything else?
mux with unix
wezterm-resize-mux.mp4
mux with ssh. Slightly easier to see the effects, but I wanted to show issue 3 which didn't show up. Issue 3 is clearly visible on my work computer.
wezterm-resize-ssh.mp4
The text was updated successfully, but these errors were encountered: