Pourquoi le rendu des séquences de caractères multi-octets est-il incroyablement lent?

Il y a environ une semaine, j'ai réalisé que la liste des fichiers dans µTorrent se bloquait moins d'une seconde chaque fois qu'un fichier avec un long nom de fichier japonais était visible. Je l'ai trouvé curieux, mais je n'avais pas vraiment le temps de m'en inquiéter à l'époque, d'autant plus qu'il n'était limité qu'à µTorrent.

Cependant, aujourd'hui, j'ai réalisé que ce n'est pas le cas. Si, par exemple, j'enregistre un fichier texte avec un nom de fichier de caractères multi-octets long et l'ouvre dans le Bloc-notes, j'obtiens des résultats étranges. Lorsque j'essaie de redimensionner la fenêtre, tout ralentit en une analyse. Je peux cependant relâcher ma prise sur la fenêtre et voir comment mon curseur se divise en deux , l'un étant contrôlé par moi et l'autre étant une sorte de "curseur fantôme" faute d'un meilleur mot qui exécute le mouvement de glissement que j'ai fait à l'origine avec le Souris. Cela ne s'applique qu'aux noms de fichiers de cette nature, et je l'ai également testé dans des applications autres que le Bloc-notes et µTorrent.

J'ai essayé de chercher des indices sur la cause de ce comportement étrange, mais je ne trouve rien. Quelqu'un ici a-t-il une idée de ce qui se passe?

Malheureusement, je ne peux pas prendre de capture d'écran car il semble que toutes les applications de capture d'écran se bloquent jusqu'à ce que le redimensionnement soit terminé avant de prendre la photo ...

Edit: j'ai enregistré une vidéo illustrant le problème. Je ne sais pas si cela aidera à identifier la cause, mais cela devrait au moins être meilleur que mon explication ci-dessus:

https://vimeo.com/58619918

Edit 2: Voici un exemple de fichier comme demandé: Notez qu'il s'agit simplement d'un fichier vide avec un nom de fichier long à plusieurs octets: http://goo.gl/bgnGP (Et pour ceux d'entre vous avec un navigateur qui ne peut pas gérer le nom de fichier, voici un fichier zip: https://dl.dropbox.com/u/55495248/multibyte.zip )

Je peux expliquer comment Unicode est géré, mais je ne peux pas vraiment répondre directement à votre question. J'ai eu de la lenteur pour la première écriture, mais une fois que c'est fait, ça redevient rapide ...

Unicode est composé de ce que nous appelons des avions. Les avions comptent 256 caractères. Dans de nombreuses situations, les polices géreront un seul plan, en partie pour éviter les fichiers très volumineux mais aussi parce que cela suffit pour de nombreuses langues (anglais, français, allemand ...). Cependant, les langues asiatiques utilisent des polices plus grandes qui couvrent plusieurs plans. Pour un jeu de caractères japonais complet, vous obtiendrez, si je ne me trompe, environ 10 avions. Le chinois est plus (surtout le chinois traditionnel!)

Lors du rendu avec de telles polices, vous devez sélectionner la police correspondante (si une police ne suffit pas pour gérer tous les caractères, le système d'exploitation bascule entre les polices pour vous; c'est sous le capot, mais cela arrive.) Cela prend du temps. De plus, la première fois que le système écrit dans cette police, il doit le charger à partir du disque. Les langues asiatiques ont de grandes polices, cela prend aussi du temps.

Enfin, et c'est probablement plus probable ce que vous rencontrez, les personnages (ou glyphes) sont généralement plus complexes. Cela signifie plus de temps pour rendre les personnages. Bien que cela puisse être fait par la carte vidéo avec OpenGL / D3D, pour les polices, ce n'est pas si bon. Vous perdez beaucoup de qualité (bien que la qualité des polices sous MS-Windows ...) C'est donc le plus souvent fait par le processeur.

Une dernière note, bien que je doute vraiment que ce soit un problème, par défaut Win7 rend les bords de la fenêtre semi-transparents. Il se pourrait que cela aggrave le problème. Cette partie du rendu, cependant, se fait très certainement avec des fonctions accélérées 2D / 3D sur votre carte vidéo.

Si votre PC rend un caractère multi-octets, cela va plus lentement car il doit peut-être faire plus d'une instruction pour traiter le caractère.

Une version 64 bits pourrait obtenir le nom 64 bits en 1 appel, le traiter en 1 appel et le stocker en 1 appel = 3 appels.

Une version 32 bits devra fonctionner avec les 32 premiers bits, puis les 32 autres, puis gérer les deux opérations:

obtenir le nom 64 bits en 3 appels, le traiter en 3 appels et le stocker en 3 appels = 9 appels.