¿Puede un emulador de terminal ser tan rápido como TTY 1-6?


59

He estado probando varios emuladores de terminal últimamente, desde el gnome-terminal incorporado, aterm, xterm, wterm, hasta rxvt. La prueba que he estado haciendo es en este orden:

  1. Abra una ventana tmux con 2 paneles
  2. El panel izquierdo será una tarea detallada intensiva como grep a /et/c -ro una simpletime seq -f 'blah blah %g' 100000
  3. El panel derecho será una ventana vim con sintaxis activada, que abre cualquier archivo que tenga más de> 100 líneas de código.

Cuando el panel izquierdo está imprimiendo una gran cantidad de resultados, el panel derecho parece ser muy lento y no responde, traté de desplazarme en vim pero toma 1-2 segundos para que cambie. Cuando intento presionar CtrlCen el panel izquierdo, espera más de 10 segundos antes de detenerse

Cuando hago lo mismo en TTY (presionando CTRL+ ALT+ ( F[1-6])), no sucede y ambos paneles responden muy bien.

He desactivado algunas configuraciones como fuentes antialias, cambio de color, uso de la configuración predeterminada y cambio a xmonad y openbox, pero no cambia nada.

El resultado de time seq -f 'blah blah %g' 100000no es realmente diferente entre estos terminales, pero la capacidad de respuesta es realmente diferente, especialmente cuando estoy ejecutando tmux de panel escupido (u otros multiplexores). Para su información, los estoy ejecutando todos en un modo maximizado.

He leído sobre terminales con memoria intermedia de trama, pero no estoy seguro de cómo funciona y cómo se puede usar para acelerar mi emulador de terminal.

Entonces mi pregunta es, ¿qué hace que el emulador de terminal sea mucho más lento que TTY? ¿Hay alguna posibilidad de hacerlo tan rápido como TTY? ¿Quizás aceleración de hardware o algo así? Una cosa que sé es que mi resolución en el servidor X cuando ejecuto un emulador de terminal maximizado es 1920x1080, y cuando ejecuto TTY es menor que eso, pero no estoy seguro de cómo esto afectaría el rendimiento.


suena como si hubiera un gran amortiguador en alguna parte
Thorbjørn Ravn Andersen

2
Tenga en cuenta que tty [1-6] no siempre son nativamente rápidos. En una de las máquinas que estoy usando, la consola de texto es muy lenta mientras que un xterm funciona decentemente.
把 友情 留 在 无 盐

Respuestas:


75

Cuando un emulador de terminal GUI imprime una cadena, tiene que convertir la cadena en puntos de código de fuente, enviar los puntos de código a un renderizador de fuente, recuperar un mapa de bits y borrar ese mapa de bits en la pantalla a través del servidor X.

El renderizador de fuentes tiene que recuperar los glifos y ejecutarlos (¿sabía que las fuentes Truetype / Opentype son programas que se ejecutan dentro de una máquina virtual en el renderizador de fuentes?). Durante el proceso de ejecución de cada glifo, se toman una cantidad increíble de decisiones con respecto a las métricas de fuente, kerning (aunque las fuentes monoespaciales y kerning no se mezclan bien), el cumplimiento de Unicode, y eso es incluso antes de llegar al rasterizador que probablemente usa sub -direccionamiento de píxeles. Luego, el terminal tiene que tomar el búfer producido por el rasterizador de fuentes y colocarlo en el lugar correcto, cuidando las conversiones de formato de píxeles, los canales alfa (para el direccionamiento de subpíxeles), el desplazamiento (que implica más borrones), etc.

En comparación, escribir una cadena en un Terminal virtual que se ejecuta en modo de texto (nota: no es una consola gráfica) implica escribir esa cadena en la memoria de video. '¡Hola Mundo!' implica escribir 13 bytes (13 palabras de 16 bits si también quieres colores). El rasterizador de fuente X aún no ha comenzado sus ejercicios de estiramiento y agrietamiento de nudillos, y hemos terminado. Es por eso que el modo de texto fue tan increíblemente importante en décadas pasadas. Es muy rápido de implementar. Incluso desplazarse es más fácil de lo que piensa: incluso en el venerable MDA y CGA basados ​​en Motorola 6845, puede desplazar la pantalla verticalmente escribiendo un único valor de 8 bits en un registro (podría ser 16 ... ha sido demasiado largo). El circuito de actualización de pantallahizo el resto Básicamente, estaba cambiando la dirección de inicio del búfer de trama.

No hay nada que pueda hacer para hacer un terminal gráfico tan rápido como un terminal en modo texto en la misma computadora. Pero anímate: ha habido computadoras con modos de texto más lentos que el terminal gráfico más lento que puedas ver en una computadora moderna. La PC original de IBM era bastante mala (DOS hizo un desplazamiento de software, suspiró). Cuando vi mi primera consola Minix en un 80286, me sorprendió la velocidad del desplazamiento (salto). El progreso es bueno.

Actualización: como acelerar el terminal

@ poige ya ha mencionado tres en su respuesta , pero aquí está mi opinión sobre ellos:

  • Disminuya el tamaño de la terminal. Mis propias terminales tienden a crecer hasta llenar las pantallas, y se vuelven más lentas a medida que lo hacen. Me exaspera, me molestan las terminales gráficas, luego las cambio de tamaño y todo es mejor. :)
  • (@poige) Use un emulador de terminal diferente. Puede obtener un gran aumento de velocidad a costa de algunas características modernas. xtermy rxvtfunciona muy bien, tiene un fantástico emulador de terminal. Sospecho que sus pruebas pueden haber demostrado que funcionan mejor que las 'modernas'.
  • (@poige) No use fuentes escalables. 1986 puede llamar y solicitar la devolución de sus terminales, pero no puede negar que son más rápidos. ;)
  • (@poige) Agilice el rasterizador de fuente desactivando el direccionamiento y las sugerencias de suavizado / subpíxel. La mayoría de ellos permiten anulaciones en las variables de entorno, por lo que no tiene que hacer esto globalmente. Nota: no tiene sentido si elige una fuente de mapa de bits.
  • Esto dolerá más: no use (múltiples paneles en)tmux - ejecute dos terminales separadas una al lado de la otra. Cuando tmuxmuestra dos paneles, tiene que usar directivas de terminal para mover mucho el cursor. Aunque las bibliotecas de terminales modernas son muy rápidas y buenas para la optimización, todavía están robando bytes del ancho de banda de su terminal sin procesar. Para mover el cursor a una fila arbitraria en un terminal compatible con DEC VT, envía ESC [ row ; col H. Eso es de 6 a 10 bytes. Con múltiples terminales, está segregando el trabajo, eliminando la necesidad de posicionamiento, optimización, almacenamiento en búfer y todo lo demás curses, y haciendo un mejor uso de múltiples núcleos de CPU.

55
+1, pero lo de tmux es aún más complicado que solo enviar algunos códigos de escape adicionales. Los terminales están destinados a desplazar toda la ventana, no la mitad. Entonces, cuando tmux tiene que mover todo el texto en el panel izquierdo hacia arriba una línea, no puede simplemente crear una nueva línea y dejar que el terminal lo mueva hacia arriba, tiene que volver a dibujar todo el panel.
Patrick

1
¡Muy bien! Me olvide de eso. Aunque ha habido terminales que pueden desplazar parte de la pantalla (IIRC se llamaba parte 'protectora' de la pantalla, se usaba para formularios, etc.), nunca fue particularmente flexible, y probablemente no sea compatible con emuladores de terminales modernos. Aunque encuentre algunas directivas obsoletas realmente extrañas que todavía se implementan hoy.
Alexios

Respondiendo esto después de 3 años, pero espero que alguien encuentre esto útil. Noto el retraso solo cuando hago una división vertical en mi vim (sí, incluso NERDTree), pero la división normal no parece ser un problema durante el desplazamiento.
chillido

17

Mientras tanto, @Alexios ha descrito bastante bien todas las razones, puedo mencionar varias cosas, que alivian relativamente el dolor:


1
Además, y este es el doloroso, disminuya el tamaño del terminal (el OP está usando una ventana de 1920x1200px). Me encantan los terminales grandes, y los míos tienden a crecer hasta que se vuelven casi tan grandes como la pantalla, pero la velocidad del terminal disminuye a medida que crece el terminal. Incluso konsole(que yo prefiero).
Alexios

3
konsolerealiza actualizaciones de pantalla diferidas: en lugar de mostrar la salida de inmediato, espera un poco más de tiempo para obtener más actualizaciones. Es por eso que funciona tan bien, hasta el punto de ser totalmente receptivo con la prueba de esfuerzo del OP.
ninjalj

2
Es bastante seguro que la representación de fuentes se almacena en caché en algún momento. No creo que los píxeles que representan la letra f se vuelvan a representar a partir de la definición vectorial cada vez que se copia en un mapa de píxeles. (a menos que deba representarse con un nuevo tamaño o un nuevo ángulo). No discutiré el hecho de que hay algunas fuentes de mapas de bits realmente agradables, que pueden ser la mejor opción solo para la apariencia, si existen para el tamaño que desea.
Peter Cordes
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.