Por que a renderização de seqüências de caracteres multibyte é incrivelmente lenta?

Question

Cerca de uma semana atrás, percebi que a lista de arquivos no µTorrent ficaria pendurada por menos de um segundo sempre que um arquivo com um nome de arquivo japonês longo estivesse visível. Eu achei curioso, mas eu realmente não tinha tempo para me preocupar com isso na época, especialmente porque era limitado apenas ao µTorrent.

No entanto, hoje percebi que não é. Se eu, por exemplo, salvar um arquivo de texto com um nome de arquivo de caractere multibyte longo e abri-lo no bloco de notas, obtenho alguns resultados estranhos. Quando tento redimensionar a janela, tudo fica mais lento. Eu posso, entretanto, liberar minha pegada na janela e ver como meu cursor se divide em dois , um sendo controlado por mim e o outro sendo uma espécie de "cursor fantasma" por falta de uma palavra melhor que execute arrastando o movimento que eu fiz originalmente com o mouse. Isso se aplica somente a nomes de arquivos dessa natureza, e eu os testei em aplicativos que não sejam o Notepad e o µTorrent também.

Eu tentei procurar por pistas sobre o que está causando esse comportamento estranho, mas não consigo encontrar nada. Alguém aqui tem alguma ideia do que está acontecendo?

Infelizmente, não consigo fazer uma captura de tela, pois parece que todos os aplicativos de captura de tela estão pendurados até que o redimensionamento esteja completo antes de tirar a foto ...

Editar: gravei um vídeo demonstrando o problema. Não tenho certeza se isso ajudará a identificar a causa, mas deve pelo menos ser melhor do que minha explicação acima:

link

Editar 2: Aqui está um arquivo de amostra conforme solicitado: Observe que é simplesmente um arquivo vazio com um nome de arquivo longo de vários bytes: link (E para aqueles com um navegador que não pode lidar com o nome do arquivo, aqui está um arquivo zip: link )

    

Answer 1

Eu posso explicar como o Unicode está sendo tratado, mas não posso responder diretamente à sua pergunta. Eu tive lentidão para a primeira gravação, mas quando isso é feito, fica rápido de novo ...

Unicode é composto do que chamamos de planos. Planos são 256 caracteres. Em muitas situações, as fontes manipulam um plano, em parte para evitar arquivos muito grandes, mas também porque é suficiente para muitos idiomas (inglês, francês, alemão ...). No entanto, os idiomas asiáticos fazem uso de fontes maiores que abrangem vários planos. Para um conjunto completo de caracteres japoneses, você tem, se estiver correto, cerca de 10 planos. Chinês é mais (especialmente chinês tradicional!)

Ao renderizar com essas fontes, você tem que selecionar a fonte correspondente (se uma fonte não for suficiente para lidar com todos os caracteres, o sistema operacional alterna entre as fontes para você; isso acontece, mas acontece). demorado. Além disso, a primeira vez que o sistema grava nessa fonte, ele precisa carregá-lo do disco. Idiomas asiáticos com fontes grandes, isso também leva tempo.

Finalmente, e provavelmente é mais provável que você esteja encontrando, os caracteres (ou glifos) são geralmente mais complexos. Isso significa mais tempo para renderizar os personagens. Embora isso possa ser feito pela placa de vídeo com OpenGL / D3D, para fontes, isso não é tão bom. Você perde muita qualidade (embora a qualidade da fonte em MS-Windows ...) Por isso, é mais frequentemente feita pelo processador.

Uma última nota, embora eu realmente duvide que isso seja uma preocupação, por padrão, o Win7 torna as bordas da janela semitransparentes. Pode ser que isso acrescente ao problema. Esta parte da renderização, no entanto, é certamente feita com funções 2D / 3D aceleradas em sua placa de vídeo.

    

Answer 2

Se o seu pc renderizar um caractere multibyte, ele será mais lento porque talvez ele tenha que fazer mais de uma instrução para processar o caractere.

Uma versão de 64bits poderia obter o nome de 64 bits em uma chamada, processá-la em uma chamada e armazená-la em uma chamada = 3 chamadas.

Uma versão de 32bits terá que trabalhar com os primeiros 32 bits, depois os outros 32, e então gerenciar ambas as operações:

obtenha o nome de 64 bits em 3 chamadas, processe-o em 3 chamadas e armazene-o em 3 chamadas = 9 chamadas.