wsl2+vcsxsrv 终端延迟的问题。

[Evovil]

遇到个很奇怪的问题当使用 wsl+vcxsrv 的时候

我用的是 i3 终端是 urxvt 在终端输入字符的时候肉眼可见的延迟，超级不爽。

但是！

当我在旁边打开个 chrome ， 然后跑个刷新率测试网页 比如这个 https://www.testufo.com/framerates#count=6&background=none&pps=1440

终端就没有延迟了丝般顺滑，把网页关掉，延迟又来了，打开又没了。。。 初步怀疑是终端的刷新率太低？

vcxsrv 的 xrander 似乎不能设置 screen 的刷新率。

有大佬知道怎么解决这个问题吗？

[ruanimal]

不是有 wslg 了吗

[cnbatch]

正如楼上所言，换用 WSLg 。

x11 转发最初不是为图形界面而设计的，所以一旦转发图形界面就会有效率问题。
https://superuser.com/questions/1217280/why-is-x11-forwarding-so-inefficient

我个人发现，在 4K 显示器 + x11-forwarding 的时候，只要浏览网页时滚动速度一快起来就会感觉到画面掉帧。分辨率越高，效果越明显。

而浏览器跑刷新率正好会让 x11 转发出极为大量的绘图指令和图像数据，终端操作的图形指令流混在其中。
比喻起来的话，效果大约是原本的小水管浇水，在浏览器跑刷新率时变成了路边消火栓喷水。

如果还是想继续用 x11 转发，那么可以试试关掉 TCP 的 Nagle 算法（以 PuTTY 为例，Connection 节点就有这个选项），也许会好一点。
更详细的设置可以参考美国布鲁克黑文国家实验室的推荐设置
https://drupal.star.bnl.gov/STAR/comp/sofi/facility-access/ssh-stable-con

[cnbatch]

尴尬，有个地方稍微说得不太完整。

"x11 转发最初不是为图形界面而设计的，所以一旦转发图形界面就会有效率问题。"

这句应该这样讲

"ssh 转发最初不是为图形界面而设计的，所以一旦转发 x11 图形界面就会有效率问题"


我当时只顾着看 PuTTY 的 Connection 各项设置都把自己搞糊涂了。


然后我又意外发现开启 /关闭 SSH 压缩原来也会对图形性能带来影响，估计是因为数据量大并且吃 CPU 性能，如果 CPU 太忙，或者 CPU 单核性能不太好的话，一压一解双重负担造成 X11 转发性能下降。

以快速刷页面甚至看视频为例，开启压缩的表现是，幻灯片滚动得比较快一点，但键鼠操作会有一点迟滞感，同时 CPU 风扇转得挺厉害；关闭压缩后的表现是，依然还是幻灯片，但出现了窗帘效应（画面刷新从上往下滚），键鼠响应是快了点但没什么用，我按个右键时，菜单上部确实很快就出现了，但接下来的画面却是幻灯片式刷出来……

我是用公司给的旧电脑（ X260 ，i5-6300U + 16G RAM ）连接 4K 显示器做试验的，Win10 20H1 。
（要不是我工作用的台式机才 8G RAM ，肯定不会去领取这种电脑。对，公司够抠门的，我自己家的电脑再烂都不会这样）
今天已经退了回去，重新申请在公司服务器上给我开个 Linux 虚拟机。

进一步证实 SSH 确实不适合转发图形界面。

[Evovil]

@cnbatch 其实你说的是对的，x11 并不是为了图形界面转发而设计的（或者说不完全是）
尤其是桌面控制器 比如 i3 xfce 等 这类有很多 bitmaps/textures 的性能会非常的差。
x11 转发一些小和比较少 textures 的应用程序 ui 会比较好。
转发桌面或者浏览器类应用 rdp/vnc 才是首选，但是在 rdp/vnc 的压缩和延迟上如何达到平衡是个挺困难的问题。

这类方案其中一个就是 parsec ， 通过 h.264 h.65 配合硬解，牺牲一部分画质的情况下达到高帧率 60fps 的转发。不过在 linux 没有 host

x11 转发个 QT 应用，vscode 或者转发个 terminal gvim/neovim 这类的是很好用的.
kernel.org 对 x 也并不怎么上心。
可能对他们来说用 x 的都是异端

[Evovil]

顺带我的问题解决了。。
是 windows IME 挂入 vcxsrv 的时候的一个问题
把 IME 切换到 English （不是 pinyin 的 english ）
就可以解决。

[cnbatch]

@Evovil 想不到连输入法都能造成影响😲

感觉 SSH X11 这事有点玄学的味道了