* James Turner -- Thursday 05 May 2005 10:54:
> I don't have much time to delve into this right now (hah!), but I  
> have some log calls in my local build, which have been fairly  
> consistent (haven't tested since your changes, Melchior - when I do,  
> I'll post those numbers).

Would be interesting. (But, of course, I didn't mean to say that the
topic is only worth to be discussed if you provide numbers. :-)  

> time between idle_state 0 and idle_state 1000
>       33 sec
>      10 sec
>      10 sec

Of course, the idle_state < 1000 will now take much longer. By about
the same amount that the pre-idle-loop is now shorter (+ a few times
rendering the splash screen, which will probably be much less than one
second altogether). I really really don't expect fgfs to take longer
for overall startup time, though. Of course, your reported 90 seconds
sound dramatic, almost unbearable. It's only around 30 seconds here.
I'd like to know how fgfs spends that extra minute on Apples. (Of course,
the time depends on the used options. Using AI takes probably longer,
or using a crowded airport like KSFO.)

> The third phase, *after* idle-state 1000, is the bit I was  
> referring to when I talked about starvation;

That's when all the scenery objects are loaded. The behavior was changed
a few months ago: before that, the 3D view appeard although not all objects
were loaded yet, which lead to some annoying stuttering on takeoff. Now
fgfs waits until all is loaded. You can get the old behavior like so

  $ fgfs --prop:/sim/sceneryloaded-override=1

> while it's doing this   
> wait, I see the splash screen, and see log output from subsystems  
> frequently (traffic manager, clouds, ephemeris), but it seems to sit  
> there for ages before showing the cockpit + scenery.

Yes, loading apt/nav data and initializing the subsystems are the
slowest parts by far.


Flightgear-devel mailing list

Reply via email to