我最近一直在尝试各种终端模拟器,从内置的 gnome-terminal、aterm、xterm、wterm 到 rxvt。我一直在做的测试是按以下顺序进行的:
grep a /et/c -r
或一个简单的time seq -f 'blah blah %g' 100000
当左窗格打印大量输出时,右窗格似乎非常缓慢且无响应,我尝试在 vim 中滚动,但需要 1-2 秒才能更改。当我尝试按下CtrlC左窗格时,它在停止之前等待超过 10 秒
当我在 TTY 中做同样的事情时(按CTRL+ ALT+( F[1-6])),它不会发生,并且两个窗格都非常敏感。
我已经关闭了一些配置,例如抗锯齿字体、着色、使用默认设置以及更改为 xmonad 和 openbox,但它并没有改变任何东西。
time seq -f 'blah blah %g' 100000
这些终端之间的结果并没有真正不同,但是响应能力确实不同,尤其是当我运行 spitted pane tmux(或其他多路复用器)时。仅供参考,我以最大化模式运行所有这些。
我已经阅读了有关帧缓冲终端的内容,但不确定它是如何工作的以及如何使用它来加速我的终端模拟器。
所以我的问题是,是什么让终端模拟器比 TTY 慢得多?有没有可能让它像TTY一样快?也许硬件加速或什么?。我知道的一件事是,我在运行最大化终端模拟器时在 X 服务器中的分辨率是 1920x1080,而当我运行 TTY 时它小于这个,但我不确定这会如何影响性能。
Ale*_*ios 77
当 GUI 终端仿真器打印出一个字符串时,它必须将字符串转换为字体代码点,将代码点发送到字体渲染器,取回位图并通过 X 服务器将该位图blit显示到显示器上。
字体渲染器必须检索字形并运行它们(您是否知道 Truetype/Opentype 字体是在字体渲染器中的虚拟机内运行的程序?)。在运行每个字形的过程中,在字体度量、字距调整(尽管等宽字体和字距调整不能很好地混合)、Unicode 合规性方面做出了大量的决定,这甚至是在我们到达可能使用 sub 的光栅化器之前- 像素寻址。然后终端必须获取字体光栅化器产生的缓冲区并将其传送到正确的位置,处理像素格式转换、alpha 通道(用于子像素寻址)、滚动(涉及更多blitting)等。
相比之下,将字符串写入以文本模式运行的虚拟终端(注意:不是图形控制台)涉及将该字符串写入视频内存。'你好,世界!' 涉及写入 13 个字节(如果您还需要颜色,则为 13 个 16 位字)。X 字体光栅化器甚至还没有开始它的拉伸练习和指关节开裂,我们已经完成了。这就是为什么文本模式在过去几十年中如此重要的原因。这是非常快实施。甚至滚动也比您想象的要容易:即使在古老的基于摩托罗拉 6845 的 MDA 和 CGA 上,您也可以通过将单个 8 位值写入寄存器(可能是 16 位……这太长了)来垂直滚动屏幕。屏幕刷新电路做了剩下的。您实际上是在更改帧缓冲区的起始地址。
在同一台计算机上,没有什么可以使图形终端与文本模式终端一样快。但是请记住:有些计算机的文本模式比您在现代计算机上可能看到的最慢的图形终端要慢。最初的 IBM PC 非常糟糕(DOS 做了软件滚动,叹气)。当我在 80286 上看到我的第一个 Minix 控制台时,我对(跳跃)滚动的速度感到惊讶。进步是好的。
更新:如何加速终端
@ poige在他的回答中已经提到了三个,但这是我自己的看法:
xterm
并且rxvt
工作得很好,它有一个很棒的终端模拟器。我怀疑您的测试可能表明它们比“现代”的表现更好。tmux
——并排运行两个独立的终端。当tmux
显示两个窗格时,它必须使用终端指令来大量移动光标。尽管现代终端库速度非常快并且擅长优化,但它们仍然会从您的原始终端带宽中窃取字节。要将光标移动到兼容 DEC VT 的终端上的任意行,请发送ESC [ row ; col H
. 那是 6-10 个字节。使用多个终端,您将工作分开,无需定位、优化、缓冲和所有其他curses
工作,并更好地利用多个 CPU 内核。poi*_*ige 17
同时@Alexios 已经很好地描述了所有原因,我可以提到几件事,它们相对减轻了痛苦:
Terminal
,Terminus
——这真的很棒),konsole
. 归档时间: |
|
查看次数: |
10904 次 |
最近记录: |