Como o piscar do cursor é implementado em emuladores de terminal GUI?

Sua pergunta mistura dois conceitos: cursor piscando e texto piscando.

O Terminal GNOME (VTE) suportou o cursor piscando por muito tempo, e eu adicionei suporte a texto piscando 5 anos atrás. Deixe-me compartilhar três detalhes interessantes sobre o suporte a texto intermitente, esperando que você goste deles :)

Esta não é uma resposta à sua pergunta (postei uma resposta real separadamente), é apenas um comentário lateral adicional.

Um aspecto interessante foi: quando exatamente piscar o texto?

A velocidade de intermitência do texto deve estar vinculada à velocidade de intermitência do cursor ou deve ser uma propriedade diferente? Seguimos com a mesma velocidade, sequestrando essa opção. IIRC konsoleusa freqüência diferente para os dois.

Vários terminais com texto piscando devem piscar ao mesmo tempo? Nossa conclusão foi que sim, eles deveriam, caso contrário, poderia ser muito irritante (como se o texto piscando não fosse irritante para começar). Quando "ligar" ou "desligar" o texto está vinculado ao relógio do sistema.

Piscar o cursor sempre reinicia com um estado "ligado" completo após cada pressionamento de tecla. Devemos manter esse comportamento? A conclusão foi sim, manter esse comportamento.

O cursor e o texto devem piscar sincronizadamente? Espero que seja fácil ver que não podemos ter tudo ao mesmo tempo, um dos possíveis critérios deve ser relaxado. Então não, esses dois não estão sincronizados.

Esta não é a única forma possível de responder a estas questões, mas sim a forma que encontrámos para fazer mais sentido.

Para implementar o suporte a texto intermitente, não importa quando vemos as sequências correspondentes \e[5mou \e[25mde escape. A barra de rolagem pode ser definida em sua posição não padrão, mostrando o conteúdo da rolagem. Obviamente, para cada célula, precisamos rastrear todas as cores e atributos decorativos, inclusive se devemos piscar essa célula. O que importa é se existe tal célula dentro da viewport atual no momento.

Às vezes, o VTE precisa repintar a tela inteira; no entanto, às vezes, apenas uma parte da tela (onde o conteúdo foi alterado) é repintada.

Um dos critérios era: se não há texto piscando na viewport (como na grande maioria dos casos), não devemos ativar o terminal a cada 0,6 segundos ou mais para não fazer nada (ou pior: repintar o mesmo). Isso é importante para economizar energia, vida útil da bateria do laptop, etc.

Por muito tempo, pensei em um cronômetro periódico. Sempre que o texto piscante for pintado, inicie um cronômetro periódico que entra em ação toda vez que o estado piscante muda. Em seguida, repintamos a tela (de preferência apenas as partes relevantes).

Mas então: como sabemos quando parar esse cronômetro periódico? Por muito tempo não vi uma resposta clara e fácil para isso.

Então a ficha caiu. Não vamos pensar em cronômetro periódico. Vamos instalar apenas um temporizador único, no momento em que o texto piscando na tela precisa mudar seu estado. Essa repintura, se ainda houver texto piscando na viewport, instalará o próximo temporizador único e assim por diante, até que o conteúdo não queira mais piscar. O preço dessa solução sólida e supersimples é uma repintura adicional desnecessária no final com a qual ninguém se importa (a menos que você depure ou strace e estude essas poll()chamadas na presença de texto piscando).

Muitas pessoas querem ver o texto piscando se é isso que o aplicativo emite. Muitas pessoas odeiam esse recurso e nunca querem ver o texto piscando. Presumivelmente, da mesma forma que o cursor pisca apenas no terminal em foco, muitas pessoas gostariam de ver o texto piscando apenas no terminal em foco.

No entanto, o Terminal GNOME também oferece uma quarta opção incomum: piscar apenas o texto nas janelas sem foco. Essa foi minha ideia, sendo o processo de pensamento: piscar é presumivelmente usado para chamar sua atenção para algo verdadeiramente inesperado e alarmante. Em sua visão focada, isso não é necessário e pode ser uma distração (por exemplo, se você está tentando consertar aquele problema sobre o qual foi alertado). No entanto, sua visão periférica é muito mais sensível a mudanças, como piscar, em vez de apenas um alerta estático sendo impresso uma vez.

Não fazemos análises em nosso software, não enviamos estatísticas (isso causaria indignação), então não tenho informações sobre a popularidade dessas quatro opções, especialmente se alguém achar essa opção "somente quando desfocada" útil.

I strace'd gnome-terminal-server, que é o processo real do Terminal GNOME.

Quando ocioso, apenas piscando o cursor, ele reside em uma poll(..., 598)chamada de kernel ou semelhante, ou seja, poll()com um tempo limite ligeiramente inferior a 0,6 segundo. (O padrão do GNOME para o ciclo completo de piscar é 1,2 segundos, portanto 0,6 segundos para cada estado "ligado" ou "desligado". Isso é reduzido pela quantidade de trabalho real que ele fez da última vez, como repintar a área do cursor.)

Isso poll()espera até que haja atividade em um dos descritores de arquivo fornecidos, ou o cronômetro termine, ou um sinal chegue.

Isso poll()não é implementado "manualmente", em vez disso, o VTE (o widget de emulação de terminal por trás do Terminal GNOME e alguns outros) registra um manipulador de eventos no loop principal do GLib, e o GLib cuida da implementação subjacente real. Cabe ao GLib decidir qual método usar, por exemplo, poderia usar select, ou epollcom timerfd, ou presumivelmente existem outras opções também.

Vejo poll()chamadas praticamente idênticas quando strace'ing konsole, e suspeito que a maioria dos outros emuladores de terminal também faz algo semelhante.

Os programas em execução no terminal (Bash ou outro) apenas emitem os códigos de escape apropriados solicitando a piscada, mas não estão envolvidos em realmente fazer isso acontecer depois disso. O programa que imprime os escapes pode ter desaparecido há muito tempo enquanto o texto piscando ainda está visível no terminal.