Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

About a week ago I realized that the file list in µTorrent would hang for less than a second whenever a file with a long Japanese file name was visible. I found it curious, but I didn't really have time to worry about it at the time, especially since it was only limited to µTorrent.

However, today I realized that it is not. If I for example save a text file with a long multibyte character file name and open it in Notepad, I get some strange results. When I try to resize the window, everything slows to a crawl. I can however release my grip on the window and see how my cursor splits in two, one being controlled by me and the other being a sort of "ghost cursor" for lack of a better word that executes the dragging motion I originally made with the mouse. This only applies to filenames of this nature, and I have tested it in applications other than Notepad and µTorrent as well.

I've tried searching for clues as to what is causing this strange behavior, but I cannot find anything. Does anyone here have any idea what's going on?

Unfortunately, I cannot take a screenshot of this as it seems like all screenshot applications hang until the resizing is complete before taking the shot...

Edit: I've recorded a video demonstrating the problem. I'm not sure whether this will help in identifying the cause but it should at least be better than my explanation above:

Edit 2: Here's a sample file as requested: Note that it's simply an empty file with a long multibyte filename: (And for those of you with a browser which can't handle the filename, here's a zip-file:

share|improve this question
I was going to upload it to YouTube at first, but apparently it's impossible without "upgrading" your account to show your real name. No thanks. I hope Vimeo's okay. – Merigrim Jan 31 '13 at 12:31
Could you tell us some details about the computer? In special, the video card you use (or is it those videoboard inside chip? Are the video drivers updated? Rendering problems can be caused by video, not Windows.... – woliveirajr Feb 5 '13 at 15:19
@woliveirajr Sure. Here's a stripped DxDiag.txt (contains info about CPU, GPU, memory, etc.): I think it's been a month or two since I updated my video drivers, I'll give it a go. – Merigrim Feb 5 '13 at 18:34
Try the first answer to the question… and see if it helps... – woliveirajr Feb 7 '13 at 11:03
and also (in the same link above) the note about – woliveirajr Feb 7 '13 at 11:04

I can explain how Unicode is being handled, but I cannot really directly answer your question. I have had slowness for the first write, but once that is done, it gets fast again...

Unicode is composed of what we call planes. Planes are 256 characters. In many situations, fonts will handle one plane, in part to avoid very large files but also because it is enough for many languages (English, French, German...). However, Asian languages make use of larger fonts that cover multiple planes. For a complete Japanese character set you'd get, if I'm correct, about 10 planes. Chinese is more (especially traditional Chinese!)

When rendering with such fonts, you have to select the corresponding font (if one font is not enough to handle all the characters, the operating system switches between fonts for you; that's under the hood, but it happens.) That is time consuming. Plus, the first time the system writes in that font, it needs to load it from disk. Asian languages having large fonts, that takes time too.

Finally, and that is probably more likely what you are encountering, the characters (or glyphs) are generally more complex. That means more time to render the characters. Although that could be done by the video board with OpenGL/D3D, for fonts, that is not so good. You lose a lot of quality (although font quality under MS-Windows...) So it is most often done by the processor.

One last note, although I would really doubt that is a concern, by default Win7 makes the window edges semi-transparent. It could be that adds to the problem. This part of the rendering, however, is most certainly done with accelerated 2D/3D functions on your video board.

share|improve this answer

If your pc render a multibyte character it goes slower because maybe it has to do more than 1 instruction to procces the character.

A 64bits version could get the 64 bits name in 1 call, proccess it in 1 call and store it in 1 call = 3 calls.

A 32bits version will have to work with the first 32 bits, then the other 32, and then manage both operations:

get the 64 bits name in 3 call, proccess it in 3 call and store it in 3 call = 9 calls.

share|improve this answer
The character fetching and storing is just a tiny fraction of the processing done. – vonbrand Apr 6 '13 at 1:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .