マルチバイト文字シーケンスのレンダリングが信じられないほど遅いのはなぜですか？
約1週間前、日本語の長いファイル名のファイルが表示されると、µTorrentのファイルリストが1秒未満でハングすることに気付きました。興味津々でしたが、特にµTorrentに限定されていたので、当時は心配する時間があまりありませんでした。
しかし、今日私はそうではないことに気づきました。たとえば、長いマルチバイト文字のファイル名でテキストファイルを保存し、それをメモ帳で開くと、奇妙な結果が得られます。ウィンドウのサイズを変更しようとすると、すべてが遅くなります。ただし、ウィンドウのグリップを放すと、カーソルが2つに分割され、1つは私によって制御され、もう1つは一種の「ゴースト」になっていることがわかります。私が最初にマウスで行ったドラッグモーションを実行するより良いWordがないために「カーソル」。これはこの種のファイル名にのみ適用され、NotepadとµTorrent以外のアプリケーションでもテストしました。
この奇妙な動作の原因について手がかりを探してみましたが、何も見つかりません。ここの誰かが何が起こっているのか考えていますか？
残念ながら、これのスクリーンショットを撮ることはできません。ショットを撮る前にサイズ変更が完了するまで、すべてのスクリーンショットアプリケーションがハングしているようです...
編集：問題を示すビデオを録画しました。これが原因の特定に役立つかどうかはわかりませんが、少なくとも上記の説明よりも優れているはずです。
編集2：リクエストに応じてサンプルファイルを次に示します。これは、長いマルチバイトファイル名を持つ単なる空のファイルであることに注意してください： http：// goo .gl/bgnGP （ファイル名を処理できないブラウザをお持ちの方のために、Zipファイルを次に示します： https://dl.dropbox.com/u/55495248/multibyte。 Zip ）
Unicodeがどのように処理されているかを説明することはできますが、あなたの質問に直接答えることはできません。私は最初の書き込みが遅くなりましたが、それが完了すると、再び速くなります...
Unicodeは、プレーンと呼ばれるもので構成されています。平面は256文字です。多くの場合、フォントは1つの平面を処理します。これは、非常に大きなファイルを回避するためだけでなく、多くの言語（英語、フランス語、ドイツ語など）でも十分であるためです。ただし、アジアの言語では、複数の平面をカバーするより大きなフォントが使用されます。完全な日本語の文字セットの場合、私が正しければ、約10機の飛行機が得られます。中国語はもっと（特に繁体字中国語です！）
このようなフォントでレンダリングする場合は、対応するフォントを選択する必要があります（1つのフォントですべての文字を処理できない場合、オペレーティングシステムはフォントを切り替えます。これは内部にありますが、発生します）。これには時間がかかります。さらに、システムがそのフォントで初めて書き込むときは、ディスクからロードする必要があります。フォントが大きいアジアの言語も時間がかかります。
最後に、おそらくそれがあなたが遭遇しているものである可能性が高いですが、文字（またはグリフ）は一般により複雑です。つまり、キャラクターをレンダリングするための時間が長くなります。それはOpenGL/D3Dを備えたビデオボードで行うことができますが、フォントの場合、それはあまり良くありません。品質が大幅に低下します（ただし、MS-Windowsではフォントの品質が低下します）。そのため、ほとんどの場合、プロセッサによって行われます。
最後にもう1つ注意してください。これが懸念事項であるかどうかは疑わしいと思いますが、デフォルトでは、Win7はウィンドウの端を半透明にします。それが問題を悪化させる可能性があります。ただし、レンダリングのこの部分は、ビデオボード上の高速化された2D/3D関数を使用して確実に実行されます。