终端仿真器可以和TTY 1-6一样快吗?


59

最近,我一直在尝试各种终端仿真器,从内置的gnome-terminal,aterm,xterm,wterm到rxvt。我一直在按以下顺序进行测试:

  1. 打开带有2个窗格的tmux窗口
  2. 左窗格将是一个冗长的任务,例如grep a /et/c -r或一个简单的time seq -f 'blah blah %g' 100000
  3. 右窗格将是一个启用了语法的vim窗口,打开包含超过100行代码的任何文件。

当左窗格打印大量输出时,右窗格似乎非常缓慢且无响应,我尝试在vim中滚动,但更改需要1-2秒。当我尝试CtrlC按左窗格时,它会等待10秒钟以上才停止

当我在TTY中执行相同的操作时(按CTRL+ ALT+(F[1-6])),则不会发生,并且两个窗格都响应迅速。

我已经启用了一些配置,例如抗锯齿字体,上色,使用默认设置以及更改为xmonad和openbox,但它没有任何改变。

time seq -f 'blah blah %g' 100000在这些终端之间,的结果并没有真正的不同,但是响应性确实有所不同,尤其是当我运行分散面板tmux(或其他多路复用器)时。仅供参考,我以最大化模式运行它们。

我已经阅读了有关帧缓冲终端的信息,但不确定如何工作以及如何使用它来加速终端仿真器。

所以我的问题是,是什么使终端仿真器比TTY慢得多?是否有可能使其达到TTY的速度?也许是硬件加速之类的?我知道的一件事是,当运行最大化的终端仿真器时,我在X服务器上的分辨率为1920x1080,而当我运行TTY时,分辨率会小于此分辨率,但是我不确定这将如何影响性能。


听起来像有一个很大的缓冲地方
托尔比约恩Ravn的安德森

2
注意tty [1-6] 并非总是很快。在我使用的其中一台计算机上,文本控制台非常慢,而xterm却表现良好。
把友情留在无盐

Answers:


75

当GUI终端仿真器打印出一个字符串时,它必须将字符串转换为字体代码点,将代码点发送到字体渲染器,取回位图,然后通过X服务器将该位图blit到显示器。

字体渲染器必须检索字形并运行它们(您是否知道Truetype / Opentype字体是在字体渲染器中的虚拟机内部运行的程序?)。在运行每个字形的过程中,就字体度量,字距调整(尽管等宽字体和字距调整不佳),Unicode合规性做出了疯狂的决定,而这甚至是在到达可能使用sub像素寻址。然后,终端必须取下字体光栅化程序生成的缓冲区,并将其blit到正确的位置,以处理像素格式转换,alpha通道(用于子像素寻址),滚动(涉及更多的 blitting)等等。

相比之下,将字符串写入以文本模式运行的虚拟终端(注意:不是图形控制台)涉及将该字符串写入视频内存。'你好,世界!' 涉及写入13个字节(如果需要颜色,也要写入13个16位字)。X字体光栅化程序甚至还没有开始其拉伸练习和指关节破裂,到此我们完成了。这就是为什么文本模式在过去几十年如此重要的原因。这是非常快实施。甚至滚动也比您想像的要容易:即使在久负盛名的基于Motorola 6845的MDA和CGA上,也可以通过将单个8位值写入寄存器来垂直滚动屏幕(可能是16,这太长了)。屏幕刷新电路剩下的了。您实际上是在更改帧缓冲区的起始地址。

同一台计算机上,您无法做得像文本终端一样快地完成图形终端。但请振作起来:有些计算机的文本模式比您在现代计算机上看到的最慢的图形终端要慢。最初的IBM PC非常糟糕(叹气,DOS进行了软件滚动)。当我在80286上看到我的第一个Minix控制台时,我对(跳转)滚动的速度感到惊讶。进步是好的。

更新:如何加速终端

@ poige回答中已经提到了三个,但这是我自己的看法:

  • 减小终端的尺寸。我自己的终端机趋向于增长,直到它们填满屏幕为止,并且这样做会变慢。我很生气,对图形终端感到恼火,然后我调整了它们的大小,一切都变好了。:)
  • (@poige)使用其他终端仿真器。您可以以某些现代功能为代价获得巨大的速度提升。xterm并且rxvt工作得非常好,它具有出色的终端模拟器。我怀疑您的测试可能表明它们的性能优于“现代”的性能。
  • (@poige)不要使用可缩放字体。1986年可能会打电话要求其终端,但您不能否认它们的速度更快。;)
  • (@poige)通过关闭抗锯齿/子像素寻址和提示功能来简化字体光栅化程序。它们中的大多数都允许在环境变量中进行覆盖,因此您不必全局执行此操作。注意:如果选择位图字体,则毫无意义。
  • 这将给您带来最大的伤害:不要使用(多个窗格)tmux -并排运行两个单独的终端。当tmux显示两个窗格时,它必须使用终端指令在很多地方移动光标。即使现代的终端库非常快速且擅长优化,它们仍在从原始终端带宽中窃取字节。要将光标移动到DEC VT兼容终端上的任意行,请发送ESC [ row ; col H。那是6到10个字节。使用多个终端,您可以隔离工作,无需进行定位,优化,缓冲和所有其他curses工作,而可以更好地利用多个CPU内核。

5
+1,但是tmux事情甚至比发送一些额外的转义码还要复杂。终端旨在滚动整个窗口,而不是滚动整个窗口。因此,当tmux必须将左窗格中的所有文本上移一行时,它不能仅创建新行并让终端将其上移,就必须重新绘制整个窗格。
Patrick

1
非常正确!我忘记了。虽然已经过可能滚动屏幕的部分终端(IIRC它被称为“保护”屏幕的一部分-这是用于表单等),这是从来没有特别灵活,而且很可能不被现代终端仿真器的支持。即使您发现某些真正奇怪的过时指令至今仍在执行。
Alexios 2012年

三年后回复此邮件,但希望有人觉得这有用。我只有在我的vim中进行垂直分割时才注意到延迟(是的,甚至是NERDTree),但是在滚动过程中正常分割似乎根本没有问题。
尖叫

17

同时,@ Alexios已经很好地描述了所有原因,我可以提及几件事,它们相对减轻了痛苦:

  • 使用位图字体(TerminalTerminus-这确实很棒),
  • 关闭抗锯齿功能,或者至少考虑不使用亚像素渲染
  • 使用KDE的终端- konsole

1
另外,这是很痛苦的事情,请减小终端的大小(OP使用1920x1200px窗口)。我喜欢大型终端,而我的终端通常会一直增长直到它们变得和屏幕一样大,但是终端速度会随着终端的增长而下降。甚至konsole(我赞成)。
Alexios 2012年

3
konsole不会进行延迟屏幕更新:与其立即显示输出,不如等待一段时间以获取更多输出,以便“批量”更新。这就是为什么它表现如此出色,以至于可以完全响应OP的压力测试。
ninjalj 2013年

2
可以肯定的是,字体渲染会在某个时刻被缓存。我不认为每次将字母f复制到像素图时,都会从矢量定义中重新渲染代表字母f的像素。(除非必须以新的尺寸或新的角度进行渲染)。我不会质疑这样的事实,即有些不错的位图字体,如果碰巧以您想要的大小存在,那可能仅是外观上的最佳选择。
彼得·科德斯
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.