Support pty ICANON mode on remote window terminal processes

Issue Type: Bug

• Using Remote SSH
• Host OS: Windows 10
• Remote OS: RHEL7

I’ve noticed that the integrated terminal on remote SSH session in tmux lags when scrolling up through the terminal history. It manifests in two ways: slow response to scrolling and delayed rendering of text. In the latter case, the terminal will scroll up, but it will take a quarter of a second to render. By contrast, if I open up the same tmux session in Windows terminal, the scrolling performance is smooth.

Note that I’ve tested with all extensions disabled, and I’ve also disabled the terminal echo feature. I’ve also tested in tmux and non-tmux, and it’s noticeably worse in tmux.

VS Code version: Code 1.60.2 (7f6ab5485bbc008386c4386d08766667e155244e, 2021-09-22T12:00:31.514Z) OS version: Windows_NT x64 10.0.19043 Restricted Mode: No Remote OS version: Linux x64 3.10.0-1062.9.1.el7.jump3.x86_64

System Info

Item	Value
CPUs	Intel® Core™ i7-10875H CPU @ 2.30GHz (16 x 2304)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	31.75GB (22.58GB free)
Process Argv	–folder-uri vscode-remote://ssh-remote%2Bremote_host_l22/home/dev/git/repo–crash-reporter-id 745587e8-1a3a-48d7-afc4-0a837a16dc7e
Screen Reader	no
VM	0%

Item	Value
Remote	SSH: remote_host_l22
OS	Linux x64 3.10.0-1062.9.1.el7.jump3.x86_64
CPUs	Intel® Xeon® Gold 6154 CPU @ 3.00GHz (36 x 3000)
Memory (System)	187.19GB (16.63GB free)
VM	0%

Extensions (13)

Extension	Author (truncated)	Version
python	ms-	2021.9.1246542782
vscode-pylance	ms-	2021.9.4
jupyter-keymap	ms-	1.0.0
remote-ssh	ms-	0.65.8
vim	vsc	1.21.8
gitlens	eam	11.6.0
git-graph	mhu	1.30.0
prettify-json	moh	0.0.3
python	ms-	2021.9.1246542782
vscode-pylance	ms-	2021.9.4
jupyter	ms-	2021.8.2041215044
jupyter-keymap	ms-	1.0.0
trailing-spaces	sha	0.3.1

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonptprofiler:30281270
vsdfh931:30280409
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
vsccppwt:30364497
pythonvssor306:30344512
bridge0708:30335490
pygetstartedt2:30371810
dockerwalkthru:30370836
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedc:30364665
pythonvspyt187:30373474
pydsgst2:30361792
vsqsis400:30374798

[Tyriar]

I’m taking this back, I did some reading and I suspect it’s related to how the pty lives on the remote, not locally. A pty’s “Canonical mode” (aka cooked mode) is meant to buffer the line locally until CR is sent but that happens on the remote in our case as we’re unable to use a pty locally. So this would be working correctly for the local ssh case but not the remote ssh case. Still learning some more about this but that’s probably the reason.

The latency measurement stuff we discussed offline would definitely be handy to have though.

[Tyriar]

I learning a little more about how canonical mode works. Both bash and sh use it when outputting (to batch the lines), and only sh uses it when line editing, bash disables it to use its more advanced line editor.

You can prove this with:

• Run stty -a in both sh and bash, see icanon
• Run (sleep 2&& stty -a) & in both sh and bash, sh=-icanon, bash=icanon

Canonical mode is what causes the escapes to echo when pressing arrows for example $ asd^[[D^[[C^[[A^[[B.

So to action this we would need to implement a pty-like canonical mode “line editor” on the renderer side, and enable it depending on the icanon state of the actual pty (ie. communicate the icanon state back and forth between the pty host and the renderer).