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

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.

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.

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

• usar fuentes de mapa de bits ( Terminal, Terminusesta es realmente genial),
• desactive el suavizado o considere al menos no utilizar la representación de subpíxeles ,
• use la terminal de KDE - konsole.