Por que os emuladores de terminal ainda têm tela piscando?

Por que ainda existem artefatos visuais quando os emuladores de terminal desenham aplicativos baseados em texto? Isso em computadores recentes que renderizam jogos 3D e janelas GUI, incluindo fontes vetoriais com suavização de serrilhado sem artefatos.

Vejo regularmente os seguintes artefatos que revelam etapas intermediárias do processo de atualização de tela:

• Movimento do cursor do terminal (o cursor pisca ou salta pela tela durante a atualização)
• Rasgando (parte da tela mostra coisas antigas enquanto outra parte mostra coisas novas)
• Rolagem (a rolagem é perceptível, em vez da nova posição de rolagem ser mostrada imediatamente)

Os artefatos são vistos apenas por intervalos de menos de um segundo, e não durante a maioria das atualizações de tela, mas tendo crescido em GUIs sem cintilação, eu ainda gostaria de saber como evitá-los. Todos os artefatos acima (exceto rolagem) podem ser vistos, por exemplo, no vídeo ASCIInema a seguir, uma vez que ele começa a desenhar as telas mais complexas: MapSCII - o mundo inteiro em seu console!

Também não estou falando especificamente sobre atualizações lentas. Seria bom se as atualizações fossem sempre instantâneas, mas isso nem sempre é possível devido a atrasos na rede e no processamento. O que quero dizer aqui é que telas parcialmente desenhadas geralmente são visíveis por um breve momento. Na maioria das GUIs modernas, apenas telas totalmente finalizadas são mostradas ao usuário, e artefatos de desenho parcial são muito raros.

É minha impressão que o pipeline de emulação de terminal é algo assim:

1. O usuário pressiona uma tecla no teclado
2. Kernel passa o pressionamento de tecla do driver do teclado para o sistema de janelas
3. O sistema de janelas passa o pressionamento de tecla para o emulador de terminal
4. O emulador de terminal passa o pressionamento de tecla para o dispositivo de kernel pseudoterminal (pty)
5. Pty interpreta o pressionamento de tecla e passa o resultado para o aplicativo baseado em texto
6. O aplicativo executa o comando em resposta ao pressionamento de tecla
7. O aplicativo renderiza uma nova tela (grade de células de caracteres) para o buffer interno
8. Chamadas de aplicativos cursesou outra biblioteca para converter a grade de células de caracteres em códigos de escape ANSI que renderizarão uma tela equivalente no terminal
9. A biblioteca grava esses códigos de escape ANSI no dispositivo pty
10. Pty processa os dados escritos de alguma forma
11. O emulador de terminal lê dados processados ​​de pty em alguns pedaços
12. O emulador de terminal chama o sistema de janelas para renderizar o resultado dos códigos de escape ANSI na janela do terminal

Qual das etapas acima pode retardar o processo o suficiente para que o emulador de terminal nos mostre etapas intermediárias de renderização em vez de mostrar apenas o resultado final?

• Parece que a velocidade dos terminais de hardware (conexões de porta serial) é ditada por sua taxa de transmissão, que pode ser alterada tcsetattr(), mas li em várias fontes que a configuração da taxa de transmissão não tem efeito nos dispositivos pseudoterminais (pty) usados ​​​​pelo terminal emuladores. Isso significa que os kernels Unix não limitam deliberadamente as comunicações pty?

• Os aplicativos ou bibliotecas de renderização (curses, etc.) enviam texto e códigos ANSI em várias gravações em vez de tentar se contentar com apenas uma write()?

• Os kernels Unix têm limites de tamanho em seus buffers de E/S internos, o que afeta coisas como a quantidade máxima de dados que podem ser enviados por um canal sem bloqueio. Isso afeta a renderização de telas de terminal com muitos detalhes (uma tela cheia de texto, muitas cores etc.)? Imagino que o texto combinado e os códigos de escape ANSI poderiam somar tantos dados que não cabem no buffer do driver pty, o que dividiria uma atualização de tela em várias operações de gravação pelo aplicativo e várias leituras pelo emulador de terminal. Se o emulador de terminal estivesse ansioso para exibir os resultados de cada leitura antes de processar a próxima, isso faria com que a exibição piscasse até que a leitura final em um lote fosse processada.

• Os emuladores de terminal ou drivers pty têm tempos limite deliberados para processamento em lote, de modo que seu comportamento imite mais de perto os terminais de hardware, pareça mais natural ou aborde alguma outra preocupação que foi considerada mais importante do que a velocidade de exibição?

Recentemente tem havido algum esforço para fazer novos emuladores de terminal que renderizem mais rápido (por exemplo, pré-renderizando fontes em texturas OpenGL na memória de vídeo). Mas esses esforços só parecem acelerar a renderização de uma grade de células de caracteres em um bitmap de tela uma vez que a grade foi calculada.

Parece haver algo mais acontecendo que torna essas coisas fundamentalmente lentas, mesmo em um computador muito rápido. Pense nisso: se o emulador de terminal processa todos os códigos ANSI para obter uma grade de células de caracteres antes de renderizar qualquer coisa em um bitmap de tela, então não importa quão lentas sejam as rotinas de renderização de grade de caracteres para bitmap - deve haver sem cintilação (pelo menos não o tipo de cintilação que claramente parece corresponder ao movimento do cursor em um terminal de hardware, que é o que vemos com frequência). Mesmo que o emulador de terminal levasse um segundo inteiro para desenhar qualquer grade de células de caracteres na tela, simplesmente teríamos um segundo de inatividade, não um segundo de cintilação.

Um problema semelhante é que o Unix cleare os resetcomandos são incrivelmente lentos para o que fazem (da perspectiva de um usuário de GUI, eles não fazem nada mais complexo do que redesenhar um bitmap). Talvez por motivos relacionados.