Um emulador de terminal pode ser tão rápido quanto TTY 1-6?

Question

Eu tenho tentado vários emuladores de terminal ultimamente, desde o gnome-terminal interno, aterm, xterm, wterm, até rxvt. O teste que tenho feito é nesta ordem:

1. Abra uma janela do tmux com 2 painéis
2. O painel esquerdo será uma tarefa detalhada, como grep a /et/c -r ou um simples time seq -f 'blah blah %g' 100000
3. O painel direito será uma janela vim com a sintaxe ativada, abrindo qualquer arquivo que tenha mais de > 100 linhas de código.

Quando o painel esquerdo está imprimindo muita saída, o painel direito parece estar muito lento e sem resposta, eu tentei rolar no vim, mas leva 1-2 segundo para ele mudar. Quando tento pressionar Ctrl C no painel esquerdo, ele espera por mais de 10 segundos antes de parar

Quando eu faço a mesma coisa em TTY (pressionando CTRL + ALT + ( F [1-6] )), não acontecer e ambos os painéis são muito responsivos.

Eu mudei algumas configurações, como as fontes antialias, a mudança de cor, use as configurações padrão e mude para xmonad e openbox, mas isso não muda nada.

O resultado de time seq -f 'blah blah %g' 100000 não é realmente diferente entre esses terminais, mas a capacidade de resposta é realmente diferente, especialmente quando estou executando o painel spitted tmux (ou outros multiplexadores). FYI, eu estou correndo todos eles em um modo maximizado.

Eu li sobre terminais com frame buffer mas não tenho certeza de como isso funciona e como ele pode ser usado para acelerar meu emulador de terminal.

Então, minha pergunta é: o que torna o emulador de terminal mais lento que o TTY? Existe alguma possibilidade de torná-lo tão rápido quanto o TTY? Talvez aceleração de hardware ou algo assim? Uma coisa que eu sei, minha resolução no servidor X ao executar um emulador de terminal maximizado é 1920x1080, e quando eu estou executando o TTY é menor que isso, mas não tenho certeza de como isso afetaria o desempenho.

    

Answer 1

Quando um emulador de terminal GUI imprime uma string, ele precisa converter a string em pontos de código da fonte, enviar os pontos de código para um renderizador de fontes, recuperar um bitmap e blit esse mapa de bits para a exibição através do servidor X.

O renderizador de fontes precisa recuperar os glifos e executá-los (você sabia que as fontes Truetype / Opentype são programas em execução dentro de uma máquina virtual no renderizador de fontes?). Durante o processo de execução de cada glifo, um número insano de decisões é feito com respeito a métricas de fonte, kerning (embora fontes monoespaçadas e kerning não se misturem bem), conformidade Unicode, e isso antes mesmo de chegarmos ao rasteriser que provavelmente usa sub endereçamento de pixels. O terminal então tem que pegar o buffer produzido pelo rasteriser da fonte e colocá-lo no lugar certo, cuidando das conversões de formato de pixel, canais alfa (para endereçamento sub-pixel), rolagem (que envolve mais blitting), et cetera.

Em comparação, escrever uma string em um Terminal Virtual em execução no modo de texto (nota: não em um console gráfico) envolve gravar essa string na memória de vídeo. "Hello, World!" Envolve escrever 13 bytes (13 palavras de 16 bits, se você quiser cores também). O rasteriser da fonte X ainda não iniciou seus exercícios de alongamento e quebra de junta, e pronto. É por isso que o modo de texto foi incrivelmente importante em décadas passadas. É muito rápido de implementar. Mesmo a rolagem é mais fácil do que você pensa: mesmo no venerável MDA e CGA baseados no Motorola 6845, você poderia rolar a tela verticalmente escrevendo um único valor de 8 bits em um registrador (poderia ser 16 ... já faz muito tempo). A atualização da tela circuito fez o resto. Você estava essencialmente alterando o endereço inicial do buffer de quadros.

Não há nada que você possa fazer para fazer um terminal gráfico tão rápido quanto um terminal de modo de texto no mesmo computador . Mas lembre-se: tem havido computadores com modos de texto mais lentos do que o terminal gráfico mais lento que você provavelmente verá em um computador moderno. O IBM PC original era muito ruim (o DOS rodava software, suspirava). Quando vi meu primeiro console Minix em um 80286, fiquei impressionado com a velocidade da rolagem (de salto). O progresso é bom.

Atualização: como acelerar o terminal

@ poige já mencionou três em sua resposta , mas aqui está minha opinião sobre eles:

• Diminua o tamanho do terminal. Meus próprios terminais tendem a crescer até preencherem as telas, e ficam lentos quando fazem isso. Eu fico exasperado, incomodado com terminais gráficos, então eu os redimensiono e tudo fica melhor. :)
• (@ poige) Use um emulador de terminal diferente. Você pode obter um enorme aumento de velocidade ao custo de alguns recursos modernos. xterm e rxvt funcionam muito bem, tem um fantástico emulador de terminal. Eu suspeito que seus testes podem ter mostrado que eles têm um desempenho melhor que os "modernos".
• (@ poige) Não use fontes escaláveis. 1986 pode ligar e pedir seus terminais de volta, mas você não pode negar que eles são mais rápidos. ;)
• (@ poige) Elimine o rasteriser da fonte desativando o endereçamento e as insinuações de anti-aliasing / sub-pixel. A maioria permite substituições em variáveis de ambiente, portanto, você não precisa fazer isso globalmente. Nota: sem sentido, se você escolher uma fonte de bitmap.
• Isso vai doer mais: não use (vários painéis em) tmux - execute dois terminais separados lado a lado. Quando tmux exibe dois painéis, ele precisa usar diretivas de terminal para mover muito o cursor. Mesmo que as bibliotecas de terminais modernos sejam muito rápidas e boas na otimização, elas ainda estão roubando bytes de sua largura de banda de terminal bruta. Para mover o cursor para uma linha arbitrária em um terminal compatível com DEC VT, envie ESC [ row ; col H . Isso é 6-10 bytes. Com vários terminais, você está segregando o trabalho, eliminando a necessidade de posicionamento, otimização, armazenamento em buffer e todas as outras coisas que o curses faz e aproveitando melhor os vários núcleos de CPU.

Answer 2

Enquanto isso @Alexios descreveu bem todas as razões, posso mencionar várias coisas, que aliviam relativamente a dor:

• use fontes bitmap ( Terminal , Terminus - isso é ótimo),
• desative o anti-aliasing, ou considere pelo menos não usar a renderização de subpixel ,
• use o terminal do KDE - konsole .