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

Terminfo/tmux sync feature does not work #999

Closed
poetaman opened this issue Aug 5, 2021 · 16 comments
Closed

Terminfo/tmux sync feature does not work #999

poetaman opened this issue Aug 5, 2021 · 16 comments
Labels
bug Something isn't working

Comments

@poetaman
Copy link

poetaman commented Aug 5, 2021

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:

     Sync    Start (parameter is 1) or end (parameter is 2) a synchronized update.

Here's a video show the problem:

syncwez.mp4

Environment (please complete the following information):

  • OS: macOS 11.5
  • Version: wezterm 20210804-162508-e3acbd59
  • U.S.

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 alacritty/alacritty#4904 (comment), and since alacritty implemented the feature: alacritty/alacritty#4768

P.S. entire TERMINFO EXTENSIONS section from man tmux:

TERMINFO EXTENSIONS
     tmux understands some unofficial extensions to terminfo(5).  It is not normally necessary to set these manually, instead the terminal-features option should be used.

     AX      An existing extension that tells tmux the terminal supports default colours.

     Bidi    Tell tmux that the terminal supports the VTE bidirectional text extensions.

     Cs, Cr  Set the cursor colour.  The first takes a single string argument and is used to set the colour; the second takes no arguments and restores the default cursor colour.  If set, a sequence such as this may be used to change
             the cursor colour from inside tmux:

                   $ printf '\033]12;red\033\\'

     Cmg, Clmg, Dsmg, Enmg
             Set, clear, disable or enable DECSLRM margins.  These are set automatically if the terminal reports it is VT420 compatible.

     Dsbp, Enbp
             Disable and enable bracketed paste.  These are set automatically if the XT capability is present.

     Dseks, Eneks
             Disable and enable extended keys.

     Dsfcs, Enfcs
             Disable and enable focus reporting.  These are set automatically if the XT capability is present.

     Smol    Enable the overline attribute.

     Smulx   Set a styled underscore.  The single parameter is one of: 0 for no underscore, 1 for normal underscore, 2 for double underscore, 3 for curly underscore, 4 for dotted underscore and 5 for dashed underscore.

     Setulc, ol
             Set the underscore colour or reset to the default.  The argument is (red * 65536) + (green * 256) + blue where each is between 0 and 255.

     Ss, Se  Set or reset the cursor style.  If set, a sequence such as this may be used to change the cursor to an underline:

                   $ printf '\033[4 q'

             If Se is not set, Ss with argument 0 will be used to reset the cursor style instead.

>>   Sync    Start (parameter is 1) or end (parameter is 2) a synchronized update.

     Tc      Indicate that the terminal supports the `direct colour' RGB escape sequence (for example, \e[38;2;255;255;255m).

             If supported, this is used for the initialize colour escape sequence (which may be enabled by adding the `initc' and `ccc' capabilities to the tmux terminfo(5) entry).

             This is equivalent to the RGB terminfo(5) capability.

     Ms      Store the current buffer in the host terminal's selection (clipboard).  See the set-clipboard option above and the xterm(1) man page.

     XT      This is an existing extension capability that tmux uses to mean that the terminal supports the xterm(1) title set sequences and to automatically set some of the capabilities above.

@poetaman poetaman added the bug Something isn't working label Aug 5, 2021
@wez
Copy link
Owner

wez commented Aug 5, 2021

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 alacritty/alacritty#4904 (comment)

@poetaman
Copy link
Author

poetaman commented Aug 6, 2021

@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 #999 (comment)

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.

@poetaman
Copy link
Author

poetaman commented Aug 6, 2021

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.

@nicm
Copy link

nicm commented Aug 6, 2021

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.

@poetaman
Copy link
Author

poetaman commented Aug 6, 2021

@nicm I tried these settings in my tmux conf file:

  1. Did not change anything:
set -g default-terminal "tmux-256color"
set -ag terminal-overrides ",xterm-256color:RGB,xterm-256color:Sync"
  1. Adds spurious escape characters to all new panes:
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?

@nicm
Copy link

nicm commented Aug 6, 2021

Logs?

@nicm
Copy link

nicm commented Aug 6, 2021

If you have Sync in your terminfo, do not add it with terminal-features or terminal-overrides.

@nicm
Copy link

nicm commented Aug 6, 2021

It looks like this terminal supports \033[>q so you could try this and see if tmux detects this itself: newsync.diff.txt

@poetaman
Copy link
Author

poetaman commented Aug 6, 2021

@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.

@nicm
Copy link

nicm commented Aug 6, 2021

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

@poetaman
Copy link
Author

poetaman commented Aug 6, 2021

@nicm I have attached screencasts comparing wezterm and alacritty for same setup (even same session).

  1. First see wezterm, and lag:
wezterm.mp4
  1. Next see alacritty (please pardon the late night typing in the video):
alacritty.mp4

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 alacritty/alacritty@3c61e07

"... 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."

@wez
Copy link
Owner

wez commented Aug 6, 2021

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.

@poetaman
Copy link
Author

poetaman commented Aug 6, 2021

@wez Setting mux_output_parser_buffer_size=1000000 did not change anything, its still that way.

@kar1
Copy link
Contributor

kar1 commented Aug 7, 2021

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.

@wez
Copy link
Owner

wez commented Sep 6, 2021

Based on your comments in #1102 (comment) it sounds like this is actually working for you now, so I'm closing this!

@wez wez closed this as completed Sep 6, 2021
listx added a commit to listx/syscfg that referenced this issue Jan 2, 2022
For whatever reason, using alacritty-xtermlike does not work even if we
install the terminfo entries. This is a semi-broken workaround for
now (24-bit colors don't actually work).

If we don't do this, we run into an odd issue where the panes get
littered with text like

    =2s

which appears to be a tmux thing (it is observable in tmux server logs).
This issue might be relevant: wez/wezterm#999.
@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
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants