Closed poetaman closed 3 years ago
wezterm nightly builds implement this spec: https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036
For tmux to have flicker free updates then tmux itself needs to support using that sequence for its output.
I'm not sure if tmux supports that for input (so tmux itself knows when the embedded application is sync'd), for its output, or for both input and output.
The terminfo option you mentioned doesn't match the synchronized output spec that wezterm implements; I think you probably want Sync=\E[?2026%?%p1%{1}%-%tl%eh
per this comment https://github.com/alacritty/alacritty/issues/4904#issuecomment-872093226
@wez I compiled with Sync=\E[?2026%?%p1%{1}%-%tl%eh
added to wezterm, xterm-256color, tmux-256color terminfo nothing changed.
Here's what I had:
1) In wezterm.lua I put term="wezterm",
and then for second experiment term="xterm-256color",
2) In tmux conf files I have:
set -g default-terminal "tmux-256color"
set -ag terminal-overrides ",xterm-256color:RGB"
set -ag terminal-features ",sync"
Nothing changed with `Sync=\E[?2026%?%p1%{1}%-%tl%eh``
Do you think I am missing something?
@nicm could comment your question regarding tmux https://github.com/wez/wezterm/issues/999#issuecomment-893858660
For Alacritty, I have set term to be xterm-256color, and it seems to have implemented it things better than every other terminal I have tried this on. Even multiple >>yes <string>
doesn't make the cursor flicker in another pane.
Also, I just updated kitty term (had not used it since installing a 6 months ago), and without doing anything manually to its terminfo, it just worked. The previous version had the same flickering issue reported here.
Adding Sync
to terminal-features
will replace it with the DCS escape sequence, try adding it to terminal-overrides
with the SM 2026 sequence instead.
@nicm I tried these settings in my tmux conf file:
set -g default-terminal "tmux-256color"
set -ag terminal-overrides ",xterm-256color:RGB,xterm-256color:Sync"
set -g default-terminal "tmux-256color"
set -ag terminal-overrides ",xterm-256color:RGB,xterm-256color:Sync=\E[?2026%?%p1%{1}%-%tl%eh"
At this point all of my terminfos too have this setting Sync=\E[?2026%?%p1%{1}%-%tl%eh
compiled into them.
Am I missing something?? or is the syntax incorrect?
Logs?
If you have Sync
in your terminfo, do not add it with terminal-features
or terminal-overrides
.
It looks like this terminal supports \033[>q
so you could try this and see if tmux detects this itself: newsync.diff.txt
@nicm I tried with your patch, it slows down wezterm even more with >>yes test
running in one of the panes. But the cursor flickering is gone with your patch. Though the delay between typing a character in an adjacent vim window and it appearing in vim seems to become much longer (unusably longer).
I have tried the inbuilt paning-windowing system of wezterm, and it does not have any of these problems. So seems there is some missing link between wezterm and tmux. I moved completely to tmux for paning-windowing given its more portable way to do that among other benefits for my workflow.
A terminal managing multiple panes/windows itself is always likely to be faster than with tmux because they do not need to feed two input streams into one output stream, limited by the tty buffer size (which on macOS is small) and using one cursor. But there is no reason it should necessarily be slower than other terminals.
If you are running with any -v
, tmux will be much much slower than without. Don't test for performance with logging on.
Are you splitting panes left-right or top-bottom? If the terminal does not support margins, the former will be slower than the latter.
If you do tmux display -p '#{client_discarded}'
, is it nonzero and does it increase? If so, then the terminal does not seem able to accept the data volume so tmux will be doing full redraws instead of incremental updates which can be appear less responsive (although better than not responsive at all).
@nicm I have attached screencasts comparing wezterm and alacritty for same setup (even same session).
1) First see wezterm, and lag:
2) Next see alacritty (please pardon the late night typing in the video):
I think your patch might be still good, if I have some more reasonable log printing instead of atrocious >>yes test
, then there isn't such lag while typing in the pane with vim.
Not sure if the difference in behavior of alacritty and wezterm is because of their own performance numbers (where tmux might not be able to help). For example read the commit message of from alacritty repo https://github.com/alacritty/alacritty/commit/3c61e075fef7b02ae0d043e4a4e664b8bc7221e9
"... Overall this has managed to reduce the time it takes to collect all renderable content from ~7-8ms in my large grid test to just ~3-4ms."
I tried with your patch, it slows down wezterm even more with
>>yes test
running in one of the panes. But the cursor flickering is gone with your patch. Though the delay between typing a character in an adjacent vim window and it appearing in vim seems to become much longer (unusably longer).
This could be a performance/tuning issue in wezterm; there's a lot that's in flux in the nightly builds at the moment.
You may want to try setting: mux_output_parser_buffer_size=1000000
and see if that helps.
@wez Setting mux_output_parser_buffer_size=1000000
did not change anything, its still that way.
I also observed the lag with flickering of the cursor in the tmux pane when running yes test
in another tmux pane. The non-tmux panes are not affected. The mux_output_parser_buffer_size=1000000
setting fixes it for me, i.e. everything is smooth without flickering. I tested it on a rather slow laptop with x11 and wezterm 20210806-214445-e9ad4376.
Based on your comments in https://github.com/wez/wezterm/issues/1102#issuecomment-913094184 it sounds like this is actually working for you now, so I'm closing 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.
Describe the bug
Cursor flickers in a tmux pane when there is activity in another tmux pane. Tmux has a new sync feature that syncs the updates before rendering a frame (afaik I understand). This is made possible by some new sync feature in terminfo.
From
man tmux
's TERMINFO EXTENSIONS section:Here's a video show the problem:
https://user-images.githubusercontent.com/71736629/128301405-fd7f845e-ffbf-4a43-9bfb-fbee0a39abb7.mp4
Environment (please complete the following information):
To Reproduce
Open tmux, create a few panes, run
>>yes test
in one pane, open nvim/vim in another and try typing something.I tried adding
Sync=\EP=%p1%ds\E\\,
to wezterm.ti and recompiling it, it didn't change anything with that.Also, I tried with my modified xterm-256color. It didn't work with that either...
This used to be a problem on alacritty, iTerm2, etc. But not since I have followed the steps here https://github.com/alacritty/alacritty/issues/4904#issuecomment-872614318, and since alacritty implemented the feature: https://github.com/alacritty/alacritty/pull/4768
P.S. entire TERMINFO EXTENSIONS section from
man tmux
: