为什么渲染多字节字符序列的速度如此之慢？

大约一周前，我意识到，只要看到长日语文件名的文件，µTorrent中的文件列表就会挂起不到一秒钟。我发现它很好奇，但当时我真的没有时间担心它，特别是因为它仅限于µTorrent。

但是，今天我意识到事实并非如此。例如，如果我用长字节字符文件名保存一个文本文件并在记事本中打开它，则会得到一些奇怪的结果。当我尝试调整窗口大小时，一切都会变慢。但是，我可以松开窗口的握把，看看我的光标如何分成两部分，一个是由我控制，另一个是一种“幽灵光标”，因为缺少一个更好的词来执行我最初使用鼠标拖动动作鼠。这仅适用于这种性质的文件名，我已经在记事本和µTorrent以外的应用程序中对其进行了测试。

我试图寻找有关导致这种奇怪行为的原因的线索，但是我什么也找不到。这里有人知道发生了什么吗？

不幸的是，我无法对此截图，因为似乎所有的截图应用程序都挂起，直到重新调整大小后再拍摄...

编辑：我录制了演示问题的视频。我不确定这是否有助于确定原因，但至少应比我上面的解释更好：

https://vimeo.com/58619918

编辑2：这是根据要求提供的示例文件：请注意，这只是一个空文件，具有长的多字节文件名：http : //goo.gl/bgnGP（对于那些使用无法处理文件名的浏览器的人，这里是一个zip文件：https : //dl.dropbox.com/u/55495248/multibyte.zip）

我可以解释Unicode的处理方式，但是我无法真正直接回答您的问题。我第一次写的时候很慢，但是一旦完成，它又很快了...

Unicode由我们称为飞机的飞机组成。平面为256个字符。在许多情况下，字体会处理一个平面，部分是为了避免很大的文件，而且还因为它足以应付多种语言（英语，法语，德语...）。但是，亚洲语言使用覆盖多个平面的较大字体。对于一个完整的日语字符集，如果我是对的，您将获得大约10架飞机。中文更多（尤其是繁体中文！）

使用此类字体进行渲染时，您必须选择相应的字体（如果一种字体不足以处理所有字符，则操作系统会为您在字体之间进行切换；尽管如此，但这确实发生了。）这很浪费时间。另外，系统第一次使用该字体写入时，需要从磁盘加载它。具有大字体的亚洲语言也需要时间。

最后，这很可能是您遇到的，字符（或字形）通常更复杂。这意味着需要更多的时间来渲染角色。尽管可以通过使用OpenGL / D3D的视频板完成此操作，但是对于字体来说，效果不是很好。您会损失很多质量（尽管在MS-Windows下是字体质量...）因此，这通常是由处理器完成的。

最后一点，尽管我真的会怀疑这是一个问题，但是默认情况下，Win7使窗口边缘为半透明的。这可能会增加问题。但是，渲染的这一部分肯定是通过视频板上的2D / 3D加速功能完成的。

如果您的PC呈现多字节字符，则会变慢，因为它可能需要执行1条以上的指令来处理该字符。

64位版本可以在1个调用中获得64位名称，在1个调用中进行处理并将其存储在1个调用= 3个调用中。

32位版本必须先使用32位，再使用其他32位，然后再管理这两种操作：

在3个调用中获取64位名称，在3个调用中进行处理并将其存储在3个调用中= 9个调用。