* 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. m. _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
