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:
- Abra una ventana tmux con 2 paneles
- El panel izquierdo será una tarea detallada intensiva como
grep a /et/c -ro una simpletime seq -f 'blah blah %g' 100000 - 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.
Respuestas:
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:
xtermyrxvtfunciona muy bien, tiene un fantástico emulador de terminal. Sospecho que sus pruebas pueden haber demostrado que funcionan mejor que las 'modernas'.tmux- ejecute dos terminales separadas una al lado de la otra. Cuandotmuxmuestra 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íaESC [ 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áscurses, y haciendo un mejor uso de múltiples núcleos de CPU.fuente
Mientras tanto, @Alexios ha descrito bastante bien todas las razones, puedo mencionar varias cosas, que alivian relativamente el dolor:
Terminal,Terminusesta es realmente genial),konsole.fuente
konsole(que yo prefiero).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.