[done] Making the Options menu load faster

[Cygal]

Clicking on the Options menu makes the game feel slow here: 0.61s are spent building the menu before displaying it, which results in a very noticeable lag.

I profiled it, and the issue is in the MenuStateOptions constructor. The constructor is very long, but all time is spent retrieving the language list in Lang::getDiscoveredLanguageList(). This is called twice, once directly in the constructor, and once indirectly through Lang::getNavtiveNameFromLanguageName() (typo not mine). This means that about 500K of text is loaded twice, simply to read the NativeLanguageName property.

I can think of two real fixes:

• put the language names in another file,
• or move NativeLanguageName to the top of the language file, and add lazy-loading to Properties. This way, only one or two lines of text would be read, thus eliminating the lag.

I'm not really asking for help, just stating what I found so far since I don't know when I'll be able to contribute the fix. Real developers should spend their time on adding features. I'll scratch my itches myself!

Thanks for MegaGlest.

[titi]

Well you are right but why should it be changed? You said for you it's 0.61s which is indeed very slow ( for me its faster )but who cares ? Its fast enough. Or do you think we also have problems ingame with something similar to this ?
If not its more something to fix if smeone is bored  .  I think there are several other more important things. 

[Cygal]

MegaGlest's focus from the start was to make things work. It's also quite nicely polished as it is. For example, the original developers didn't have to add the rain effect, but they did, and the result is great. A lot of others small things make the game feel nice and fast or not, *especially* when they go unnoticed. In my opinion, there's still some work left to make MegaGlest feel more polished. This issue makes the menu transition animation stutter on my fairly old laptop (which is still way above the minimum requirements), and I think that it makes the game feel slow even when it's not. It's also possible to make an analogy with the broken window theory: with less small issues, the small issues that are left won't be left unnoticed. This is also why I take such lists so seriously. By the way, more important things take more time to work on, but I can't predict the amount of time I can spend on MegaGlest, so I prefer to work in small chunks and let the main developers to the interesting work.

It's simply attention to detail. I'm looking at all the small issues that bother me and try to fix them without taking too much of your time. I certainly agree that such issues are not worth discussing, which is why I've been explaining more the reasoning behind my choices than the actual choices themselves.

Thank you for MegaGlest.

[tomreyn]

I think it's great that Cygal is planning to contribute by improving existing features, and while I don't have the say on this, I think this approach should be welcomed and I personally appreciate it, as well as Cygals recent patches.

Since this very issue is not considered a bug but an existing feature which could be improved upon (I agree there with Titi), I've moved this thread to the feature requests forum. I think it's better placed there even though Cygal plans to come up with those improvements on his own (for now).

[GunChleoc]

I think it's a good idea tweaking it if you have the time. On my computer, it freezes long enough that you might start to wonder if the game has crashed, and my computer is less than 2 years old.

[titi]

Oh I did not get that you want to work on this cygal! You are VERY much welcome to do so! Sorry if I got you wrong here.

[Cygal]

http://paste.debian.net/215153/ contains a patch that moves language names to a file: data/langs/langs.lng. The menu construction is now instantaneous. The drawbacks are that translators cannot change the language name using Transifex.

(I first tried implementhing this by putting the language name at the top of the file and implement lazy loading in a static class function, but it changed a lot of code since I wanted to make common code static. It was also fragile since it relied on having the language name at the top of the file for good performance. I believe my patch is a better compromise.)

[GunChleoc]

Maybe you could work with ISO language codes instead of the language names? I remember having a discussion about changing the names of the lng files to ISO codes somwhere in this forum. http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

Common practice is to go with ISO 639-1: two-letter codes plus an optional two-letter country code, e.g. en_US or gd.

[tomreyn]

ISO 639-1 is already used within the language files to map files to locales, but we should also use this standard for file names in the future, this would make mapping language files with Transifex much easier, too (currently we need to manually maintain a list of mappings).

I'm not sure whether this would break Cygal's patch, though.

[Cygal]

It would be easy to change the patch once the names are changed, or change the names after the patch has been applied. I could do it myself, but I'd still need someone to commit that.

[softcoder]

svn rev#: 3965 implements a cache and a thread to offer better performance. Let me know what you think?

[Cygal]

Sounds good, many thanks! Not tested yet.