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

Cerca de uma semana atrás, percebi que a lista de arquivos no µTorrent seria interrompida por menos de um segundo sempre que um arquivo com um nome de arquivo japonês longo estivesse visível. Achei curioso, mas na verdade não tinha tempo para me preocupar com isso, especialmente porque estava limitado apenas ao µTorrent.

No entanto, hoje eu percebi que não é. Por exemplo, se eu salvar um arquivo de texto com um nome de arquivo de caracteres multibyte longo e abri-lo no Bloco de Notas, obtive alguns resultados estranhos. Quando tento redimensionar a janela, tudo fica lento. No entanto, posso soltar minha mão na janela e ver como meu cursor se divide em dois , sendo um controlado por mim e o outro como uma espécie de "cursor fantasma" por falta de uma palavra melhor que execute o movimento de arrastar que eu originalmente fiz com o cursor. rato. Isso se aplica apenas a nomes de arquivos dessa natureza, e eu o testei em outros aplicativos que não o Bloco de Notas e o µTorrent.

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

Infelizmente, não posso tirar uma captura de tela disso, pois todos os aplicativos de captura de tela ficam paralisados ​​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 ser pelo menos melhor do que minha explicação acima:

https://vimeo.com/58619918

Edit 2: Aqui está um exemplo de arquivo, conforme solicitado: Note-se que ele é simplesmente um arquivo vazio com um nome de arquivo longo de vários bytes: http://goo.gl/bgnGP (E para aqueles de vocês com um navegador que não pode lidar com o nome do arquivo, é aqui um arquivo zip: https://dl.dropbox.com/u/55495248/multibyte.zip )

Posso explicar como o Unicode está sendo tratado, mas não posso responder diretamente à sua pergunta. Eu tive lentidão na primeira gravação, mas uma vez feito isso, fica rápido novamente ...

Unicode é composto do que chamamos de aviões. Os aviões têm 256 caracteres. Em muitas situações, as fontes lidam com 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 usam fontes maiores que abrangem vários planos. Para um conjunto completo de caracteres japoneses, você receberá, se eu estiver correto, cerca de 10 aviões. Chinês é mais (especialmente chinês tradicional!)

Ao renderizar com essas fontes, é necessário 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 está oculto, mas acontece.) Isso consome tempo. Além disso, na primeira vez em 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 (apesar da qualidade da fonte no MS-Windows ...). Por isso, é feito com mais frequência pelo processador.

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

Se o seu PC renderizar um caractere multibyte, ele fica mais lento porque talvez ele precise executar mais de uma instrução para processar o caractere.

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

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

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