Perché il rendering di sequenze di caratteri multibyte è incredibilmente lento?

Circa una settimana fa mi sono reso conto che l'elenco dei file in µTorrent si sarebbe bloccato per meno di un secondo ogni volta che era visibile un file con un nome di file giapponese lungo. L'ho trovato curioso, ma in quel momento non avevo davvero il tempo di preoccuparmene, soprattutto perché era limitato a µTorrent.

Tuttavia, oggi ho capito che non lo è. Se, ad esempio, salvo un file di testo con un lungo nome di file di caratteri multibyte e lo apro in Blocco note, ottengo alcuni strani risultati. Quando provo a ridimensionare la finestra, tutto rallenta a gattonare. Posso tuttavia rilasciare la presa sulla finestra e vedere come il mio cursore si divide in due , uno è controllato da me e l'altro è una sorta di "cursore fantasma" per mancanza di una parola migliore che esegue il movimento di trascinamento che originariamente ho fatto con il topo. Questo vale solo per i nomi di file di questa natura e l'ho testato in applicazioni diverse da Blocco note e µTorrent.

Ho provato a cercare indizi su ciò che sta causando questo strano comportamento, ma non riesco a trovare nulla. Qualcuno qui ha idea di cosa sta succedendo?

Sfortunatamente, non posso fare uno screenshot di questo in quanto sembra che tutte le applicazioni di screenshot si blocchino fino al completamento del ridimensionamento prima di scattare la foto ...

Modifica: ho registrato un video che dimostra il problema. Non sono sicuro se questo aiuterà a identificare la causa, ma dovrebbe almeno essere migliore della mia spiegazione sopra:

https://vimeo.com/58619918

Modifica 2: Ecco un file di esempio come richiesto: Nota che è semplicemente un file vuoto con un lungo nome file multibyte: http://goo.gl/bgnGP (E per quelli di voi con un browser che non è in grado di gestire il nome file, ecco un file zip: https://dl.dropbox.com/u/55495248/multibyte.zip )

Posso spiegare come viene gestito Unicode, ma non posso davvero rispondere direttamente alla tua domanda. Ho avuto lentezza per la prima scrittura, ma una volta fatto, torna di nuovo veloce ...

Unicode è composto da ciò che chiamiamo aerei. Gli aerei sono 256 caratteri. In molte situazioni, i caratteri gestiranno un piano, in parte per evitare file molto grandi ma anche perché è sufficiente per molte lingue (inglese, francese, tedesco ...). Tuttavia, le lingue asiatiche fanno uso di caratteri più grandi che coprono più piani. Per un set completo di caratteri giapponesi otterrai, se avrò ragione, circa 10 aerei. Il cinese è di più (soprattutto il cinese tradizionale!)

Quando si esegue il rendering con tali caratteri, è necessario selezionare il carattere corrispondente (se un carattere non è sufficiente per gestire tutti i caratteri, il sistema operativo passa da un carattere all'altro; è sotto il cofano, ma succede.) Ciò richiede molto tempo. Inoltre, la prima volta che il sistema scrive quel font, è necessario caricarlo dal disco. Le lingue asiatiche hanno caratteri grandi, anche questo richiede tempo.

Infine, e questo è probabilmente più probabile quello che stai incontrando, i personaggi (o glifi) sono generalmente più complessi. Ciò significa più tempo per il rendering dei personaggi. Anche se ciò potrebbe essere fatto dalla scheda video con OpenGL / D3D, per i caratteri, non è così buono. Si perde molta qualità (anche se la qualità dei caratteri in MS-Windows ...) Quindi viene spesso eseguita dal processore.

Un'ultima nota, anche se dubito davvero che sia una preoccupazione, per impostazione predefinita Win7 rende i bordi della finestra semi-trasparenti. Potrebbe essere che si aggiunge al problema. Questa parte del rendering, tuttavia, è sicuramente realizzata con funzioni 2D / 3D accelerate sulla scheda video.

Se il tuo PC rende un personaggio multibyte, va più lentamente perché forse deve fare più di 1 istruzione per processare il personaggio.

Una versione a 64 bit potrebbe ottenere il nome a 64 bit in 1 chiamata, elaborarlo in 1 chiamata e memorizzarlo in 1 chiamata = 3 chiamate.

Una versione a 32 bit dovrà funzionare con i primi 32 bit, quindi con gli altri 32 e quindi gestire entrambe le operazioni:

ottenere il nome 64 bit in 3 chiamate, elaborarlo in 3 chiamate e memorizzarlo in 3 chiamate = 9 chiamate.