Buginator commented

Can't replicate this, since it works fine on XP.

Looks like a vista issue.

Buginator changed status from new to closed

Buginator changed resolution from `` to worksforme

Zarel commented

I don't see why that should be a reason to close this bug...

anonymous commented

How is this a warzone bug?

It only happens on vista, so if anything, it is either a sdl bug for vista, or a vista issue of some kind.

Zi-Chan changed status from closed to reopened

Zi-Chan changed resolution from worksforme to ``

Zi-Chan commented

It doesn't only happen on Vista. This happens at my XP Home SP3 too. It even happens at my Versions without the FMVs (only tried the FMV-Version once).
I will check, if there are some Error-Messages, when it happens next Time. Can take some Weeks, because note, that this is only happens rarely - but it should never.
I recommend Reopening for this Ticket. Even, if it was a Vista-only Bug, it is one and should be terminated.

Troglodactyl commented

I'm on XP and I never seem to have any such issue. Any chance that the problem is caused by something other than Warzone?

Buginator changed status from reopened to closed

Buginator changed resolution from `` to worksforme

Buginator commented

I don't know how I can make this any clearer, this sure don't seem like a warzone codebase issue.

Nothing in the codebase, that I can see, would cause a huge delay on startup.

This could be windows prefetch (where it loads all the libs, and whatever else into the prefetch folder), or something along those lines, or one of the libs that is being used.
Heck, it could be a VM issue, or even gfx card related, or maybe network related.

• Until someone has actual proof otherwise, then it doesn't do any good to keep this open, on something that happens randomly, and can't be recreated by me, or anyone who has access to a windows debug build & a debugger, or any relevant information to contribute.

The startup code itself hasn't been touched in a very long time.

Kamaze changed status from closed to reopened

Kamaze changed resolution from worksforme to ``

Kamaze changed blocking which not transferred by tractive

Kamaze changed blockedby which not transferred by tractive

Kamaze commented

I would like to re-open this. With the 2.2_beta1 the startup time is every time between 30 and 40 seconds. Nothing note-worthy in the logs, even with "--debug all". I also noted that after 20 seconds the SDL-Typical stderr.txt and stdout.txt are created, ~13 Seconds later I'm in the main menu.

Maybe some SDL isse, but other SDL based games fire up very quickly.

Zarel commented

This occurs once in a while for me, too, although most of the times it's just fine. In particular, the first few times after I installed Windows 7, the game took forever to start up.

Kamaze commented

The first time it took nearly 2 minutes, after starting quite a few times it is now at a boot-up time if 32 Seconds and doesn't get faster anymore. On a 3 GHz dualcore machine with 4 GB RAM.

Kamaze commented

I think I found the issue. I fired up the process-monitor from sysinternals to see what happens when Warzone 2100 boots up, and there are a lot reads to the windows fonts directory. It spends nearly the whole boot time in loading all kind of font files, like all variations of the DejaVu fonts and a lot other ones.

Seems like there is something very odd.

anonymous commented

After it caches it, it don't happen again right?

So I guess this isn't a SDL issue, but a QuesoGLC (or fontconfig or windows caching or...) issue.

I still don't know what we can do about it, therefore, I still think this is a invalid ticket.

Buginator commented

Replying to Warzone2100/old-trac-import#84 (comment:11):

After it caches it, it don't happen again right?

So I guess this isn't a SDL issue, but a QuesoGLC (or fontconfig or windows caching or...) issue.

I still don't know what we can do about it, therefore, I still think this is a invalid ticket.

^^ is me.

Kamaze commented

After it caches it, it don't happen again right?

Yes and no. It happens every start. The it only speed up a little bit after the first boot, because Windows has the loaded files still in the system cache. But the whole fonts are scanned on every startup.

I can't say where is the issue, but it is somewhat unacceptable for Windows users.

Zarel changed priority from minor to critical

Zarel commented

We've identified a cause, and it's important that we fix this soon. Because of how long the .exe takes to start, users simply assume that Warzone cannot start, and report inaccurate bugs.

There are multiple forum threads about this issue.

It's important.

Buginator commented

No we haven't. We don't know which lib is at fault.

This is from the #409 I just closed

All I can say is, it isn't a bug in warzone per se.

It is either with freetype, QuesoGLC, or fontconfig.

We don't control any of those libs, we only use them.

Best I can say is submit a bug report to them, but since I can't replicate this, and I don't know anyone with Vista on the dev team, I don't even know which of those libs is at fault with Vista.

Heck, it could be a Vista issue as well. All I know is, it works fine with XP.

And yes, I still think this should be closed!

Zarel commented

Well, then, we stop using one of those libs? We make sure we use only the fonts we bundle with, in the application directory?

Buginator changed status from reopened to closed

Buginator changed resolution from `` to invalid

Buginator commented

OK, a bit of looking, and the problem is with fontconfig.

There is nothing we can do about it, besides complain to them.

What happens is, it reads all the fonts in Vista, which takes a long time (from what I read), and it stores it in the cache.

Once the cache has been created, then it is fast.

http://fontconfig.org/wiki/

Closing this ticket (again), since we are not going to change from QuesoGLC to something else for 2.2, and the maintainer of QuesoGLC said that he will NOT use fontconfig/freetype in version .80 of QuesoGLC. He is at .73 now.

By that time, we might be using pango anyway.

Closing as invalid (not our bug). --> complain to upstream!

Buginator commented

For those that got the issue, please edit the font.conf file, and remove this line:

	<dir>WINDOWSFONTDIR</dir>

then delete your fontconfig.cache or(fontconfig\cache*.*) file, and restart the game.

Let us know if that little hack works or not.

Thanks!

Kamaze commented

Replying to [comment:18 Buginator]:

[...]

Fixes the issue. Thanks!

Zi-Chan commented

Fixes the issue at me too. Thanks :D

Kamaze commented

The issue is still in Trunk. Isn't it possible to remove this entry by default? I would say that all Windows users suffer from it.

Zarel commented

The file is in the devpkg, so it's not anywhere in "trunk" to begin with.

Buginator removed milestone (was 2.2)

Buginator commented

Milestone 2.2 deleted